> > Here is a patch that implements 'ZeroD', a simple kernel thread that uses
> Interesting idea. I see only one problem -- it allocates some memory for
> it's internal pool. Doesn't this mean that thingies that call
> __get_free_page() might be disadvantaged, such as requests for DMA buffers
> and whatnot. especially thingies that call __get_free_pages() that want a
> number of contiguous pages -- this could "fragment" memory, couldn't it?
yes. The current patch keeps the size of this pool quite limited. If there
are no major objections, i'd like to integrate the functionality right
into the global free page pool. (thus no allocation would happen, we
would operate on a sysctl+dynamics controlled fraction of the free page
pool.)
> And here's one thing:
>
> > +unsigned long get_precleared_page (void)
> > +{
> > + unsigned long flags;
> > + unsigned long page=0;
> > +
> > + save_flags(flags);
> > + cli();
> > +
> > + if (cleared_pages[first_page]) {
> > + page=cleared_pages[first_page];
> > + cleared_pages[first_page++]=0;
> > + first_page &= ZEROD_POOLSIZE-1;
> > +
> > + wake_up (&zerod_wait);
> > + }
> > +
> > + restore_flags(flags);
> > + return page;
> > +}
>
> I may not really know what I'm talking about...but shouldn't you call
> sti() after that if, or maybe even during the if, before the wake_up call?
the wake_up() call never sleeps. (as it's really just an event notifier,
and puts the 'ready' process into the global runqueue ... so it can be
called from interrupt handlers too which must never sleep)
so all this procedure does is making preallocation pool operations atomic.
The wake_up call doesnt really count in this respect, it just kicks zerod
once a page was taken off the queue. (this is a bit overdone, but if you
check out wake_up(), it simply returns as it's first action if the wait
queue is empty, ie. zerod is not sleeping.).
-- mingo