search for: imnho

...id feel pretty strongly that we should remove the > bitmap, unless we have some data to support keeping it. I don't feel as > strongly about it, but I think their critique of it is pretty valid. I think the > consensus is that the bitmap needs to go. > > The only real question IMNHO is whether we should do a power-of-2 or a > length. But, if we have 12 bits, then the argument for doing length is pretty > strong. We don't need anywhere near 12 bits if doing power-of-2. Just found the MAX_ORDER should be limited to 12 if use length instead of order, If the MAX_ORDER...

...id feel pretty strongly that we should remove the > bitmap, unless we have some data to support keeping it. I don't feel as > strongly about it, but I think their critique of it is pretty valid. I think the > consensus is that the bitmap needs to go. > > The only real question IMNHO is whether we should do a power-of-2 or a > length. But, if we have 12 bits, then the argument for doing length is pretty > strong. We don't need anywhere near 12 bits if doing power-of-2. Just found the MAX_ORDER should be limited to 12 if use length instead of order, If the MAX_ORDER...

> > 1. Current patches do a hypercall for each order in the allocator. > > This is inefficient, but independent from the underlying data > > structure in the ABI, unless bitmaps are in play, which they aren't. > > 2. Should we have bitmaps in the ABI, even if they are not in use by the > > guest implementation today? Andrea says they have zero benefits

> > 1. Current patches do a hypercall for each order in the allocator. > > This is inefficient, but independent from the underlying data > > structure in the ABI, unless bitmaps are in play, which they aren't. > > 2. Should we have bitmaps in the ABI, even if they are not in use by the > > guest implementation today? Andrea says they have zero benefits

...should remove the > bitmap, unless we have some data to support keeping it. I don't feel as > strongly about it, but I think their critique of it is pretty valid. I think the > consensus is that the bitmap needs to go. > Thanks for you clarification. > The only real question IMNHO is whether we should do a power-of-2 or a > length. But, if we have 12 bits, then the argument for doing length is pretty > strong. We don't need anywhere near 12 bits if doing power-of-2. > So each item can max represent 16MB Bytes, seems not big enough, but enough for most case. T...

...should remove the > bitmap, unless we have some data to support keeping it. I don't feel as > strongly about it, but I think their critique of it is pretty valid. I think the > consensus is that the bitmap needs to go. > Thanks for you clarification. > The only real question IMNHO is whether we should do a power-of-2 or a > length. But, if we have 12 bits, then the argument for doing length is pretty > strong. We don't need anywhere near 12 bits if doing power-of-2. > So each item can max represent 16MB Bytes, seems not big enough, but enough for most case. T...

...e the > >> bitmap, unless we have some data to support keeping it. I don't feel as > >> strongly about it, but I think their critique of it is pretty valid. I think the > >> consensus is that the bitmap needs to go. > >> > >> The only real question IMNHO is whether we should do a power-of-2 or a > >> length. But, if we have 12 bits, then the argument for doing length is pretty > >> strong. We don't need anywhere near 12 bits if doing power-of-2. > > > > Just found the MAX_ORDER should be limited to 12 if use len...

...e the > >> bitmap, unless we have some data to support keeping it. I don't feel as > >> strongly about it, but I think their critique of it is pretty valid. I think the > >> consensus is that the bitmap needs to go. > >> > >> The only real question IMNHO is whether we should do a power-of-2 or a > >> length. But, if we have 12 bits, then the argument for doing length is pretty > >> strong. We don't need anywhere near 12 bits if doing power-of-2. > > > > Just found the MAX_ORDER should be limited to 12 if use len...

> Am 30.11.2016 um 09:43 schrieb Liang Li: > > This patch set contains two parts of changes to the virtio-balloon. > > > > One is the change for speeding up the inflating & deflating process, > > the main idea of this optimization is to use bitmap to send the page > > information to host instead of the PFNs, to reduce the overhead of > > virtio data

> Am 30.11.2016 um 09:43 schrieb Liang Li: > > This patch set contains two parts of changes to the virtio-balloon. > > > > One is the change for speeding up the inflating & deflating process, > > the main idea of this optimization is to use bitmap to send the page > > information to host instead of the PFNs, to reduce the overhead of > > virtio data

...at ballooning will only occur when there is lots of actual free memory and that it will not occur when that same memory is in use as page cache. In these patches, you're effectively still sending pfns. You're just sending one pfn per high-order page which is giving a really nice speedup. IMNHO, you're avoiding doing a real bitmap because creating a bitmap means either have a really big bitmap, or you would have to do some sorting (or multiple passes) of the free lists before populating a smaller bitmap. Like David, I would still like to see some data on whether the choice between bi...

...? I think Andrea and David feel pretty strongly that we should remove the bitmap, unless we have some data to support keeping it. I don't feel as strongly about it, but I think their critique of it is pretty valid. I think the consensus is that the bitmap needs to go. The only real question IMNHO is whether we should do a power-of-2 or a length. But, if we have 12 bits, then the argument for doing length is pretty strong. We don't need anywhere near 12 bits if doing power-of-2.

...ngly that we should remove the >> bitmap, unless we have some data to support keeping it. I don't feel as >> strongly about it, but I think their critique of it is pretty valid. I think the >> consensus is that the bitmap needs to go. >> >> The only real question IMNHO is whether we should do a power-of-2 or a >> length. But, if we have 12 bits, then the argument for doing length is pretty >> strong. We don't need anywhere near 12 bits if doing power-of-2. > > Just found the MAX_ORDER should be limited to 12 if use length instead of order...

...BUG_SG? No way! (yeah evil again) > > Why aren't you constructive and pick up pick up the CONFIG flag? Because config doesn't make that much of a sense. You do not want a permanent vmalloc fallback unconditionally. Debugging option which changes the behavior completely is not useful IMNHO. Besides that who is going to enable it? > > Really, we have a fault injection framework and this sounds like > > something to hook in there. > > The testing people won't set it up. They install the "kernel-debug" > package and run the tests in it. > > I...

To get around the problem of having to change the root password every time a sys admin leaves the organization Solaris is hardened as follows. in /etc/default login. CONSOLE= Restricted permissions on su so only certain groups can run it. That way its really difficult to log in as root even if the root password is known. For OpenSSH PermitRootLogin is set to without-password and a key is

...bitmap, unless we have some data to support keeping it. I > > >> don't feel as strongly about it, but I think their critique of it > > >> is pretty valid. I think the consensus is that the bitmap needs to go. > > >> > > >> The only real question IMNHO is whether we should do a power-of-2 > > >> or a length. But, if we have 12 bits, then the argument for doing > > >> length is pretty strong. We don't need anywhere near 12 bits if doing > power-of-2. > > > > > > Just found the MAX_ORDER should be...

...ss we have some data to support keeping it. I don't feel as > > strongly about it, but I think their critique of it is pretty valid. I think the > > consensus is that the bitmap needs to go. > > > > Thanks for you clarification. > > > The only real question IMNHO is whether we should do a power-of-2 or a > > length. But, if we have 12 bits, then the argument for doing length is pretty > > strong. We don't need anywhere near 12 bits if doing power-of-2. > > > So each item can max represent 16MB Bytes, seems not big enough, > bu...

...e > >> the bitmap, unless we have some data to support keeping it. I don't > >> feel as strongly about it, but I think their critique of it is pretty > >> valid. I think the consensus is that the bitmap needs to go. > >> > >> The only real question IMNHO is whether we should do a power-of-2 or > >> a length. But, if we have 12 bits, then the argument for doing > >> length is pretty strong. We don't need anywhere near 12 bits if doing > power-of-2. > > > > Just found the MAX_ORDER should be limited to 12 if use...

...e > >> the bitmap, unless we have some data to support keeping it. I don't > >> feel as strongly about it, but I think their critique of it is pretty > >> valid. I think the consensus is that the bitmap needs to go. > >> > >> The only real question IMNHO is whether we should do a power-of-2 or > >> a length. But, if we have 12 bits, then the argument for doing > >> length is pretty strong. We don't need anywhere near 12 bits if doing > power-of-2. > > > > Just found the MAX_ORDER should be limited to 12 if use...

On Sun, 22 Apr 2018, Michal Hocko wrote: > On Sat 21-04-18 07:47:57, Matthew Wilcox wrote: > > > > He didn't want to fix vmalloc(GFP_NOIO) > > > > I don't remember that conversation, so I don't know whether I agree with > > his reasoning or not. But we are supposed to be moving away from GFP_NOIO > > towards marking regions with