Linus Torvalds wrote: > > On Fri, 8 Dec 2000, Daniel Phillips wrote: > > > > [ flush-buffers taking the page lock ] > > > > This is great when you have buffersize==pagesize. When there are > > multiple buffers per page it means that some of the buffers might have > > to wait for flushing just because bdflush started IO on some other > > buffer on the same page. Oh well. The common case improves in terms > > being proveably correct and the uncommon case gets worse a tiny bit. > > It sounds like a win. > > Also, I think that we should strive for a setup where most of the dirty > buffer flushing is done through "page_launder()" instead of using > sync_buffers all that much at all. > > I'm convinced that the page LRU list is as least as good as, if not better > than, the dirty buffer timestamp stuff. And as we need to have the page > LRU for other reasons anyway, I'd like the long-range plan to be to get > rid of the buffer LRU completely. It wastes memory and increases > complexity for very little gain, I think. > I think flushing pages instead of buffers is a good direction to take. Two things: 1. currently bdflush is setup to use page_launder only under memory pressure (if (free_shortage() ... ) Do you think that it should call page_launder regardless? 2. There are two operations here: a. starting a write-back, periodically. b. freeing a page, which may involve taking the page out of a inode mapping, etc. IOW, what page_launder does. bdflush primarily does (a). If we want to move to page-oriented flushing, we atleast need extra information in the _page_ structure as to whether it is time to flush the page back. -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/