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

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

> > Here is a patch that implements 'ZeroD', a simple kernel thread that uses
> > up CPU idle time to keep a pool of pre-zeroed pages around. Almost
> > anything that doesnt burn 100% CPU time all the time should benefit from
> > this.
>
> the patch is against a clean 2.1.20. Comments, ideas, flames welcome.
>
> + *
> + * This kernel thread keeps a pool of pre-zeroed pages. It runs at
> + * lowest possible process priority, so it will use up only idle time.
> + * It's a simple 'idle time' --> 'cleared page' converter.

> Wouldn't it be a better idea to pre-zero the pages that are to be
> used next, instead of putting aside a small pool? This way more pages
> could be zeroed when there is time, and free pages are available.
> In other words, the pool would be _all_ free pages.

yup, something like this could be done. This is the first and very simple
version. But there are quite some very subtle things to watch at when
messing around with the global Buddy a'la Linus free page pool:

the majority of __get_free_page() requests do not want zeroing. (one of
the biggest consumers is kmalloc for example).

Thus we cannot really know if the next request wants zeroing or not.
Putting the 'i'm all zeroes' information into the page pool is not good i
think, as it slows down the (common) nonzero requests. Thus i've chosen
the solution to hook this daemon into get_free_page() [which is the proper
way of requesting zeroed pages]. Maybe we should put more accent on this
fact, we should call it 'get_zeroed_page()' or something like this.

The only open issue thus is to give back these pages when we are low on
memory. I will do some statistics on how heavily zero pages are wanted.
The 'try_to_free_page' routine should first look into this prezeroed pool
then. (thus we kindof loose that page, but i think if we are low on
memory, we should do this). The next thing i'd like (if there are no major
objections against this kind of stuff :) to implement dynamic pressure
between 'try_to_free_page()' and 'get_free_page()'. try_to_free_page()
requests make the pool smaller, get_free_page() makes the pool bigger. But
this all depends on how hard zero pages are needed. If the need is very
low, then it might even make sense to put no extra code into
try_to_free_page() ... just keep around 8 pages or so.

there is one major place in the kernel which wants zeroed pages, as far as
i'm aware of, and doesnt use get_free_page(), this is when do_wp_page()
hits a zero mapping. Since __get_free_pages() can sleep, and another
process could COW the very same page [or could unshare it thus no COW
would be needed], we cannot simply allocate a zero page. What i'd like to
code up here is a 'switch_pages()' function, which switches new_page for a
prezeroed page in copy_cow_page() without sleeping. This way the zeroed
page is only used when absolutely needed. (the __get_free_page() in
do_wp_page() is slightly 'overdoing' page allocation, to avoid some races)

if the COW zero case is implemented [in 30 minutes or so :))], then zerod
will be a major player in a typical desktop workload? :)

for 100% CPU burning applications zerod makes no sense at all, so it
should be made a config option?

-- mingo



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