Messages in this thread | | | Date | Tue, 15 Nov 2005 01:50:08 -0800 | From | Paul Jackson <> | Subject | Re: [PATCH 01/05] mm fix __alloc_pages cpuset ALLOC_* flags |
| |
Nick wrote: > I was under the impression that you > introduced the exception reverted in #2 due to seeing atomic > allocation failures?!
For the record, the discussion Nick is recalling starts here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0503.3/0763.html
My motivation for letting GFP_ATOMIC requests escape cpuset confinement was not based on seeing real world events, but based on code reading.
If some GFP_ATOMIC requests fail, the system can panic. Apparently these allocations are in init and setup code, where only a really sick system could fail a kmalloc() anyway. But, back then in March 2005, I concluded that GFP_ATOMIC requests were the absolute most essential allocations to satisfy, at all costs, cpusets be damned.
This time around, when reading __alloc_pages() again, I realized that GFP_ATOMIC requests did not get the highest priority in setting watermarks. Even they had to leave some reserves behind. The only allocations allowed to ignore all mins were the special case of allocations that promised to free more memory than they were consuming, really soon now (such as an exiting task).
I figured this time that what's good for watermark setting is good for cpuset setting.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |