[lkml]   [1997]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Since no one else has stepped forward: 'ZeroD' patch

On Tue, 7 Jan 1997, Andrew E. Mileski wrote:

> > 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

> 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

 \ /
  Last update: 2005-03-22 13:38    [W:0.020 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site