Messages in this thread |  | | Date | Fri, 08 Dec 2000 14:22:27 -0800 | From | Rajagopal Ananthanarayanan <> | Subject | Re: [PATCH] Re: kernel BUG at buffer.c:827 in test12-pre6 and 7 |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |