> > the majority of __get_free_page() requests do not want zeroing. (one of
> > the biggest consumers is kmalloc for example).
>
> I don't think this is the issue - whether a page is zeroed or not
> shouldn't matter. What is important though, is knowing if the page has
> been zeroed, and hence I understand you using the pool for tracking.
if we zero a page, we should use it for requests that want zero pages, and
not for get_kmalloc_pages().
> I'd suggest that the non-zeroed page requests grab a zeroed page
> as a last resort. This would make it possible to enlarge the zeroed
> page pool considerably.
yup. But the zero pool shouldnt get too large, say block device buffers
should have higher priority. Thats why the pool size is very limited
currently.
> Ideally, perhaps all page requests should go through a single mechanism
> that maintains a circular list of all available pages - zeroed pages
> at one end, non-zeroed at the other (kinda like the inode list).
> The allocator would need to traverse the list in the opposite
> direction as 'zerod'.
Yes, something like this could be done: we could have two RMQUEUE
versions: one for prezeroed pages going forwards, and one for not
prezeroed pages, going backwards in the (fortunately) doubly linked
ringlist. There would be >zero< penalty for kmalloc(). Nice. Version #3 on
the way :)
and we dont even have to record the zeroed pages, a floating pointer is
enough that shows the boundary between the zero and nonzero area.
Sometimes one-page zeroed pages might get clustered into bigger blocks,
thus we 'loose them', but maybe this effect isnt significant.
this is going to rock. :)
-- mingo