search for: 1gib

From: Robert Hanson <roberth at abbacomm.net> > or should i be more specific with the question(s)? > the reason i ask is that i just dumped 2 gig dram in a basic > P4 Intel 3.0GHz box to play with. > regards and TIA, At more than 1GiB on Linux/x86, you must use a 4G+4G kernel (this is the default) to see more than 960MiB. This causes a signficant (10%+) performance hit. On more than 4GiB, it is worsened as more extensive paging is used. If you have 1GiB or less, you should rebuild with_out_ "HIGHMEM" support which i...

...isohybrid in the mix. I say "re-introduced" because we used isohybrid years ago but then it was not problematic either. Back then we ran it with the `-entry 4 -type 1c` options only, so no -h or -s. Also, back then all images (no matter which compression we used) were definitely far below 1GiB in size, which may be relevant information for your later question. > What's the difference, in bytes, between the non-hybrid ISO image and > the isohybrid one? Could you please provide both exact sizes? Our current stable release [1], which wasn't a hybrid ISO, is 951764992 bytes....

Hi, Ady wrote: > Let's not forget that the goal usually is to select CHS values so that > the resulting (optical and/or other) media would boot correctly in as > many systems as possible Agreed. But we now have a report about failure of 255x63 on a popular pseudo-hardware, when the ISO is presented as DVD-ROM. (Probably there is no complaint when it gets presented as hard disk.)

Hi, I''m starting to play with btrfs on my new computer. I''m running Gentoo and have compiled the 2.6.31 kernel, enabling btrfs. Now I have 2 partitions (on 2 different sata disks) that are free for me to play with, each about 375 gb in size. I wanted to create a "raid1" volume using these two partitions, so I did: # mkfs.btrfs -d raid1 /dev/sda5 /dev/sdb5 # mount

Just a small correction: Thomas Schmitt via Syslinux <syslinux at zytor.com> wrote: > > > I expect the average waste to be a bit less than 16 MB. > > Yes, but slightly misleading. For example, the "16MB average" is > > relevant for 255/63. > > We advise two geometries: -h 63 -s 32 and -h 255 -s 63. > isohybrid behavior with the first one will not

Hi, > What about '-h 255 -s 63 , ISO size 1085736960' ? -h 255 -s 63 , ISO size 1085736960 : align_factor= 4 , padding= 0 , image size= 132.000000 cylinders ----------------------------------------------------------------- Code of isohybrid_test_mockup.c : ----------------------------------------------------------------- #include <stdlib.h> #include <stdio.h> int

...time. > > Our ideas of implementation are supposed to yield the > same result. > Hmm, I am not sure. Or perhaps I am misunderstanding your code. Let me try with an example (or two). For this example, let's assume: -h 255 -s 63 ISO size: 1'085'736'960 bytes ( > 1GiB) This size happens to be a multiple of: 63, 255 and 2048 So, using these values in my suggested loop. 1_ Calculate a potential Cylinders (amount) value; Cylinders= trunc(roundup( ISO_size / (Heads * Sectors_per_track * 512)) Cylinders (1st attempt)= trunc(roundup(1085736960/(255*63*512))...

I have encountered the same problem on XCP 1.1 and XCP 1.5 beta. I tried "xe vm-memory-limits-set" command, and what I get is like [root@xcp11 ~]# xe vm-memory-limits-set static-min=1GiB dynamic-min=4GiB dynamic-max=4GiB static-max=4GiB --multiple operation failed on 9587c557-39b0-4cb1-a0e7-f2e701f287ac: You attempted an operation on a VM that was not in an appropriate power state at the time; for example, you attempted to start a VM that was already running. The parameters return...

...get a CPU > > address that low. But having a set of addresses reserved would be much > > better of course. > I'm thinking more about the top of the address space. As I understand > it, the kernel already splits the CPU virtual address space into > user/system areas (3GiB/1GiB for 32-bit IIUC), or something very > similar to that. > > Perhaps, if we can get at that information, we can use those same > definitions for GPU address space? Ah, I get what you're saying. Sure, I think that might be okay. Not sure how we would get at that information, though...

Hi, > Hopefully I am explaining it better this time. Our ideas of implementation are supposed to yield the same result. As said, i am willing to implement my proposal in a copy of isohybrid.c, if somebody wants to test it. Advantages and disadvantages should be obvious. Interested users please send util/isohybrid.c from your local SYSLINUX source code installation to me. Just to be sure

On Wed, Jul 08, 2015 at 10:18:36AM +1000, Ben Skeggs wrote: > > There's some minimal state that needs to be mapped into GPU address space. > > One thing that comes to mind are pushbuffers, which are needed to submit > > stuff to any engine. > I guess you can probably use the start of the kernel's address space > carveout for these kind of mappings actually?

...failing under some situation. Maintainers should not need to burn their brains about the reasons. Users should not blame the distro (without even reporting the problem). We are talking about an average padding of less than 2% for realistic cases, and that's just for the minimal size (around 1GiB). If users are required to download images of 3GB, adding 16MiB (on average) is less than 1%. Additionally, we are talking about an average of 16MiB of padding for "un-padded" images. Current (as of 6.03) isohybrid images are already padded (with a different algorithm), so the additi...

...e nice if the advise > for 255x63 could be changed to 252x63. Question is whether this > could cause any regressions with boot firmware. (Partition > editors should be happy with partition ends aligned to cylinder > ends.) No, the recommendation for an isohybrid image size bigger than 1GiB is still a geometry of '-h 255 -s 63'. These recommended values are not random, and are not a "decision" that can be changed. These values are the ones that most BIOS assume, and most partition editors assume. Thus, changing the recommendation to 252/63 could potentially make...

...e, 240/63, or 128/32, with the difference that "252" does not coincide with any particular size limitation while "240" and "128" partially do (note that all these pairs would still cover the relevant size we are talking about in this example of TAILS, slightly over 1GiB). There are other potential advantages for smaller values, but successfully booting as many systems as possible should be the primary target. And yet, all this doesn't really matter, as different BIOS could assume different values, whether because they use different algorithms to select CH...

Hi, > Now, I have a question: what about the "offset" parameter? How it > modifies our assumptions and calculations if the "offset" parameter is > not zero? The offset influences only the start address of the partition. The alignment goal is about the end address. So these concepts are nearly independent. Of course, partition start must be smaller than partition

Good day. Continue to research that issue. Current state: PV guest, static_min=500MiB, static_max=1GiB, dynamic=800MiB, domid=2 manually create /local/domain/2/control/feature_balloon. Do xe vm-memory-target-set uuid=... target=650MiB squeezed debug: 20120707T03:00:57Z Request for squeezed/balance-memory/3c46cc6a-c1df-deab-1aed-0b0ad939961b 20120707T03:00:57Z listdir /squeezed/rpc/request/bala...

...MIC_IRQS 2048 # endif #endif and we now can get to 338 guests (with three disks each) on our 64GiB 16 core test server. the 339th guest appears to start, but instead sits there on a blank console. 338 guests is enough for me, as my 64GiB boxes are reserved for 1GiB guests and up, and even on the 512MiB and smaller guests, the 32GiB servers rarely exceed 100 guests. Now, if you start more guests, (we started 479) while xl works, xm hangs forever. the domains we start after 338 are unpingable. Xend can not restart. xenconsoled keeps dying. We kill...

...e, then I could see the segmentation fault. I used gdb to debug, but the performance was much lower than the previous test results, and we couldn't see the errors. We thought that the problem only occurred when multiple clients wrote the same volume with a very high performance (e.g., more than 1GiB/s each client).------------------ ???? ------------------ ???: "Ben Turner"<bturner at redhat.com> ????: 2017?11?5?(???) ??3:00 ???: "???"<21291285 at qq.com>; ??: "gluster-users"<gluster-users at gluster.org>; ??: Re: [Gluster-users] glusterfs segmen...

This patch series includes a series of bugs related to p2m, ept, and PoD code which were found as part of our XenServer product testing. Each of these fixes actual bugs, and the 3.4-based version of the patch has been tested thoroughly. (There may be bugs in porting the patches, but most of them are simple enough as to make it unlikely.) Each patch is conceptually independent, so they can each

Hi, Ady wrote: > I am not so sure that using a different pair of '-h' and '-s' values > would be better than using 255/63. But 255 * 63 is not divisible by 4 and thus can cause trouble with virtual DVD-ROM. > Most BIOS and most partition editors would assume this geometry. I cannot tell for BIOSes, but partition editors have options to set heads-per-cyl and