Messages in this thread |  | | Date | Tue, 7 Jan 1997 23:24:32 +0100 (MET) | From | Ingo Molnar <> | Subject | Re: 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 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
|  |