On Thu, Jun 20, 2002 at 03:49:52PM +0100, David Laight wrote:
> On Thu, Jun 20, 2002 at 04:23:26PM +0200, Wojciech Puchar wrote:
> > > > others can have 10 partitions, one can mostly do I/O on one partition,
> > > > another spread it evenly. what i don't understand?
> > >
> > > Because you may want to say, e.g. that the swap, / and /usr partition are
> > > highter priorities.
> > > The usual way to solve this is to add more disks, but it's not always possible.
> > 
> > 
> > sounds different as an option. thanks for explanation
> 
> I've been reading this thread - and keeping quiet for a change...
> 
> I wonder if people are looking in the wrong place!
> 
> Maybe the number of queued disk write requests generated by the
> pagedaemon? (ie writes that are being done to generate free pages)
> should be restricted?
> That way it would never take too long for a read request (to page
> something in) to be executed.

precisely I think this is the wrong way of doing it. This won't help
for requests not comming from the page daemon (I guess the metadata
buffer cache is not handled by the page daemon - there are also
requests comming from raw devices). 
And to really take avantage of modern devices (with tagged queuing)
you want the request queue to be as large as possible, so that there is
always a command ready to be sent to the device. Waking up the pagedaemon to
get more requests won't be fast enouth.

> After all pages don't get freed faster if you have more writes
> scheduled.

It is with tagged queuing devices.

> 
> The other question is which pages are chosed to be invalidated?
> If someone is copying a large file, or making a large iso image,
> then you actually want to discard the pages that have been used
> earlier by the copy - rather than those used by the long standing
> X server etc.
> 
> ISTM that pages that have been used a lot of times but not in
> the immediate past should be preserved in preference to pages
> that have only been used once but very recently.
> (a naive implemtation of this wort work though...)

I think it's dependant of the workload. however an optimisation may be:
If it's a write and the whole file can't fit in memory, then make dirty pages
from this file prefered to be freed.
It should also be not too hard to detect sequencial reads or writes, which can
give another hint. 

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--