Messages in this thread |  | | Date | Fri, 21 Sep 2001 10:08:20 -0400 (EDT) | From | Bill Davidsen <> | Subject | Re: broken VM in 2.4.10-pre9 |
| |
On Fri, 21 Sep 2001, Stephan von Krawczynski wrote:
> On Thu, 20 Sep 2001 23:16:55 -0400 (EDT) Bill Davidsen <davidsen@tmr.com> > wrote: > > > On Sun, 16 Sep 2001, Stephan von Krawczynski wrote: [... snip ...] > > The problem is that when many things effect the optimal ratio of text, > > data, buffer and free space a solution which doesn't measure all the > > important factors will produce sub-optimal results. Your proposal is > > simple and elegant, but I think it's too simple to produce good results. > > See my reply to Linus' comments. > > Actually I did not really propose a method of valueing the several pros and > cons in aging itself, but a very basic idea of how this could be done without > fiddling around with page->members (like page->age) which always implies you > have to walk down a whole list to get the full picture in case of urgent need > for freeable pages. > If you age something by re-arranging its position in a list you have the > drawback of list-locking, but the gain of fast finding the best freeable pages > by simply using the first ones in that list. Even better you can add whatever > criteria you like to this aging, e.g. you could rearrange to let consecutive > pages be freed together and so on, all would be pretty easy to achieve, and > page-struct becomes even smaller. > The more I think about it the better it sounds. > Your opinion?
The list is an okay way to determine rank within a class, but I still think that there is a need for some balance between text, program data, pages loaded via i/o, perhaps more. My disquiet with the new implementation is based on a desire to avoid swapping program data to make room for i/o data (using those terms in a loose way for identification).
I would also like to have time to investigate what happens if the pages associated with a program load are handled in larger blocks, meta-pages perhaps, which would at least cause many to be loaded at once on a page fault, rather than faulting them in one at a time. I have to look at the code again in my spare time, my last serious visit was 2.2.15 or so, looking to improve SMP performance.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |