Matthew Dobson wrote:
Christoph Lameter wrote:
On Thu, 26 Jan 2006, Matthew Dobson wrote:
All subsystems will now get more complicated by having to add this
emergency functionality?
Certainly not. Only subsystems that want to use emergency pools will get
more complicated. If you have a suggestion as to how to implement a
similar feature that is completely transparent to its users, I would *love*
I thought the earlier __GFP_CRITICAL was a good idea.
Well, I certainly could have used that feedback a month ago! ;) The
general response to that patchset was overwhelmingly negative. Yours is
the first vote in favor of that approach, that I'm aware of.
to hear it. I have tried to keep the changes to implement this
functionality to a minimum. As the patches currently stand, existing slab
allocator and mempool users can continue using these subsystems without
modification.
The patches are extensive and the required changes to subsystems in order
to use these pools are also extensive.
I can't really argue with your first point, but the changes required to use
the pools should actually be quite small. Sridhar (cc'd on this thread) is
working on the changes required for the networking subsystem to use these
pools, and it looks like the patches will be no larger than the ones from
the last attempt.
I would say that the patches to support critical sockets will be
slightly more complex with mempools
than the earlier patches that used the global critical page pool with a
new GFP_CRITICAL flag.
Basically we need a facility to mark an allocation request as critical
and satisfy this request without
any blocking in an emergency situation.
Thanks
Sridhar
There surely must be a better way than revising all subsystems for
critical allocations.
Again, I could not find any way to implement this functionality without
forcing the users of the functionality to make some, albeit very minor,
changes. Specific suggestions are more than welcome! :)
Gfp flag? Better memory reclaim functionality?
Well, I've got patches that implement the GFP flag approach, but as I
mentioned above, that was poorly received. Better memory reclaim is a
broad and general approach that I agree is useful, but will not necessarily
solve the same set of problems (though it would likely lessen the severity
somewhat).
-Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
