On Fri, 19 Jan 2001, Rajagopal Ananthanarayanan wrote:
> Marcelo Tosatti wrote:
> >
>
> >
> > Now I dont see any problem with write clustering (potentially converting
> > pages if we found delayed pages). Remember that page_launder() is called
> > by each process since 2.4.1pre2, so there is no big problem if kswapd
> > blocks trying to convert pages.
>
> You are referring to writepage() doing the conversion & clustering when
> called from page_launder()? IOW, do the conversion/clustering as part of
> the memory allocation, right?
Not really .
> There are no major issues with it: infact at one point I had the
> convertpage() call out of page_launder to do conversions inplace,
> instead of waking up the page_cleaner daemon. Two potential pitfalls.
> (1) the conversion/clustering can involve memory allocation --- now
> you are allocating more memory when already trying to allocate memory
> (and in fact facing a shortage of memory) ... can the process now
> be marked PF_MEMALLOC?
Yes, PF_MEMALLOC can be used.
The clustering should be limited (or even removed) if we're under critical
memory shortage. These are tuning issues which I'm sure we will have to
look more carefully later.
> (2) potential locking problems in the FS. If the original memory allocation
> is done under a lock, as is the case in XFS, which holds the IOLOCK,
> then the convert call should be able to trylock & bail.
The cost of fixing this (not so easy) problems is worth IMHO.
One of the most interesting parts of this is that we really avoid code
replication --- even swap will use the write clustering scheme.
|