using writepage to start io

Quoted 3 lines · Chris Mason

This has been tested a little more now, both ext2 (1k, 4k) and reiserfs. dbench and iozone testing don't show any difference, but I need to spend a little more time on the benchmarks.

It's impressive that such seemingly radical surgery on the vm innards is a) possible and b) doesn't make the system perform noticably worse.

Quoted 5 lines

The idea is that using flush_dirty_buffers to start i/o under memory pressure is less than optimal. flush_dirty_buffers knows the oldest dirty buffer, but has no page aging info, so it might not flush a page that we actually want to free.

Note that the fact that buffers dirtied by ->writepage are ordered by time-dirtied means that the dirty_buffers list really does have indirect knowledge of page aging. There may well be benefits to your approach but I doubt this is one of them.

It's surprising that 1K buffer size isn't bothered by being grouped by page in their IO requests. I'd have thought that this would cause a significant number of writes to be blocked waiting on the page lock held by an unrelated buffer writeout.

The most interesting part of your patch to me is the anon_space_mapping. It's nice to make buffer handling look more like page cache handling, and get rid of some special cases in the vm scanning. On the other hand, buffers are different from pages in that, once buffers heads are removed, nobody can find them any more, so they can not be rescued. Now, if I'm reading this correctly, buffer pages *will* progress on to the inactive_clean list from the inactive_dirty list instead of jumping that queue and being directly freed by the page_cache_release.

Maybe
this is good because it avoids the expensive-looking __free_pages_ok.

This looks scary:

+ index = atomic_read(&buffermem_pages) ;

Because buffermem_pages isn't unique. This must mean you're never doing page cache lookups for anon_space_mapping, because the mapping+index key isn't unique. There is a danger here of overloading some hash buckets, which becomes a certainty if you use 0 or some other constant for the index. If you're never doing page cache lookups, why even enter it into the page hash?

That's all for now. It's a very interesting patch.

Quoted 4 lines · I wrote:

Note that the fact that buffers dirtied by ->writepage are ordered by time-dirtied means that the dirty_buffers list really does have indirect knowledge of page aging. There may well be benefits to your approach but I doubt this is one of them.

A problem is that under memory pressure, we'll flush a buffer that has been dirty for a long time, even if we are constantly redirtying it and have it more or less pinned. This might not be common enough to cause problems, but it still isn't optimal. Yes, it is a good idea to flush that page at some time, but under memory pressure we want to do the least amount of work that will lead to a freeable page.

Quoted 9 lines

The most interesting part of your patch to me is the anon_space_mapping. It's nice to make buffer handling look more like page cache handling, and get rid of some special cases in the vm scanning. On the other hand, buffers are different from pages in that, once buffers heads are removed, nobody can find them any more, so they can not be rescued. Now, if I'm reading this correctly, buffer pages *will* progress on to the inactive_clean list from the inactive_dirty list instead of jumping that queue and being directly freed by the page_cache_release.

Without my patch, it looks to me like refill_inactive_scan will put buffer cache pages on the inactive dirty list by calling deactivate_page_nolock. page_launder catches these by checking page->buffers, and calling try_to_free_buffers which starts the io.

So, the big difference now is just that page_launder sees the page is dirty, and uses writepage to start the io and try_to_free_buffers only waits on it. The rest should work more or less the same.

Quoted 6 lines

Maybe
this is good because it avoids the expensive-looking __free_pages_ok.

This looks scary:

Quoted 8 lines

+ index = atomic_read(&buffermem_pages) ;

Because buffermem_pages isn't unique. This must mean you're never doing page cache lookups for anon_space_mapping, because the mapping+index key isn't unique. There is a danger here of overloading some hash buckets, which becomes a certainty if you use 0 or some other constant for the index. If you're never doing page cache lookups, why even enter it into the page hash?

path of least surprise I suppose; I knew add_to_page_cache_locked() would do what I wanted in terms of page setup, if there's a better way feel free to advise ;-) No page lookups are done on the buffer cache pages.

Quoted 6 lines · Chris Mason

Quoted 4 lines · I wrote:

Note that the fact that buffers dirtied by ->writepage are ordered by time-dirtied means that the dirty_buffers list really does have indirect knowledge of page aging. There may well be benefits to your approach but I doubt this is one of them.

Quoted 6 lines

A problem is that under memory pressure, we'll flush a buffer that has been dirty for a long time, even if we are constantly redirtying it and have it more or less pinned. This might not be common enough to cause problems, but it still isn't optimal. Yes, it is a good idea to flush that page at some time, but under memory pressure we want to do the least amount of work that will lead to a freeable page.

But we don't have a choice. The user has set an explicit limit on how long a dirty buffer can hang around before being flushed. The old-buffer rule trumps the need to allocate new memory. As you noted, it doesn't cost a lot because if the system is that heavily loaded then the rate of dirty buffer production is naturally throttled.

If you must enter it into the page hash you'd be safer generating a random number for the page index. But why not just take what you need from add_to_page_cache_locked:

On Monday, August 06, 2001 12:38:01 AM +0200 Daniel Phillips

Quoted 15 lines · <[email protected]> wrote:

Quoted 6 lines · Chris Mason

Quoted 4 lines · I wrote:

Note that the fact that buffers dirtied by ->writepage are ordered by time-dirtied means that the dirty_buffers list really does have indirect knowledge of page aging. There may well be benefits to your approach but I doubt this is one of them.

Quoted 7 lines

A problem is that under memory pressure, we'll flush a buffer that has been dirty for a long time, even if we are constantly redirtying it and have it more or less pinned. This might not be common enough to cause problems, but it still isn't optimal. Yes, it is a good idea to flush that page at some time, but under memory pressure we want to do the least amount of work that will lead to a freeable page.

Quoted 6 lines

But we don't have a choice. The user has set an explicit limit on how long a dirty buffer can hang around before being flushed. The old-buffer rule trumps the need to allocate new memory. As you noted, it doesn't cost a lot because if the system is that heavily loaded then the rate of dirty buffer production is naturally throttled.

there are at least 3 reasons to write buffers to disk

1) they are too old
2) the percentage of dirty buffers is too high
3) you need to reclaim them due to memory pressure

There are 3 completely different things; there's no trumping of priorities.

Under memory pressure you write buffers you have a high chance of freeing, during write throttling you write buffers that won't get dirty again right away, and when writing old buffers you write the oldest first.

This doesn't mean you can always make the right decision on all 3 cases, or that making the right decision is worth the effort ;-)

Quoted 6 lines

there are at least 3 reasons to write buffers to disk

1) they are too old
2) the percentage of dirty buffers is too high
3) you need to reclaim them due to memory pressure

Quoted 2 lines

There are 3 completely different things; there's no trumping of priorities.

There is. If your heavily loaded machine goes down and you lose edits from 1/2 an hour ago even though your bdflush parms specify a 30 second update cycle you'll call the system broken, whereas if it runs 5% slower under heavy write+swap load that's just life.

Quoted 8 lines

Under memory pressure you write buffers you have a high chance of freeing, during write throttling you write buffers that won't get dirty again right away, and when writing old buffers you write the oldest first.

This doesn't mean you can always make the right decision on all 3 cases, or that making the right decision is worth the effort ;-)

If we need to do write throttling we should do it at the point where we still know its a write, i.e., somewhere in sys_write.

Some time after
writes are throttled (specified by bdflush parms) all the old write buffers will have worked their way through to the drives and your case
(3) gets all the bandwidth. I don't see a conflict, except that we don't have such an upstream write throttling mechanism yet. We sort-of have one in that a writer will busy itself trying to help out with lru scanning when it can't get a free page for the page cache. This has the ugly result that we have bunches of processes spinning on the lru lock and we have no idea what the queue scanning rates really are. We can do something much more intelligent and predictable there and we'll be a lot closer to being able to balance intelligently between your cases.

By the way, I think you should combine (2) and (3) using an and, which gets us back to the "kupdate thing" vs the "bdflush thing".

Quoted 7 lines · On Monday, August 06, 2001 07:39:47 AM +0200 Daniel Phillips wrote:

Quoted 6 lines · Chris Mason

there are at least 3 reasons to write buffers to disk

1) they are too old
2) the percentage of dirty buffers is too high
3) you need to reclaim them due to memory pressure

Quoted 7 lines

Quoted 2 lines

There are 3 completely different things; there's no trumping of priorities.

There is. If your heavily loaded machine goes down and you lose edits from 1/2 an hour ago even though your bdflush parms specify a 30 second update cycle you'll call the system broken, whereas if it runs 5% slower under heavy write+swap load that's just life.

Ok, we're getting caught up in semantics here. I'm not saying kupdate should switch over to write buffers that might get reclaimed instead of old buffers. There still needs to be proper flushing of old data.

I am saying that it should be possible to have the best buffer flushed under memory pressure (by kswapd/bdflush) and still get the old data to disk in time through kupdate.

Quoted 2 lines

By the way, I think you should combine (2) and (3) using an and, which gets us back to the "kupdate thing" vs the "bdflush thing".

Perhaps, since I think they would be handled in roughly the same way.

Quoted 3 lines

I am saying that it should be possible to have the best buffer flushed under memory pressure (by kswapd/bdflush) and still get the old data to disk in time through kupdate.

Yes, to phrase this more precisely, after we've submitted all the too-old buffers we then gain the freedom to select which of the younger buffers to flush.

When there is memory pressure we could benefit by skipping over some of the sys_write buffers in favor of page_launder buffers. We may well be able to recognize the latter by looking for !bh->b_page->age. This method would be an alternative to your writepage approach.

Quoted 5 lines

Quoted 3 lines

By the way, I think you should combine (2) and (3) using an and, which gets us back to the "kupdate thing" vs the "bdflush thing".

Perhaps, since I think they would be handled in roughly the same way.

(warning: I'm going to drift pretty far off the original topic now...)

I don't see why it makes sense to have both a kupdate and a bdflush thread.

We should complete the process of merging these (sharing flush_dirty buffers was a big step) and look into the possibility of adding more intelligence about what to submit next. The proof of the pudding is to come up with a throughput-improving patch, not so easy since the ore in these hills has been sought after for a good number of years by many skilled prospectors.

Note that bdflush also competes with an unbounded number of threads doing wakeup_bdflush(1)->flush_dirty_buffers.

On Monday, August 06, 2001 06:13:20 PM +0200 Daniel Phillips

Quoted 7 lines · <[email protected]> wrote:

Quoted 3 lines

I am saying that it should be possible to have the best buffer flushed under memory pressure (by kswapd/bdflush) and still get the old data to disk in time through kupdate.

Yes, to phrase this more precisely, after we've submitted all the too-old buffers we then gain the freedom to select which of the younger buffers to flush.

Almost ;-) memory pressure doesn't need to care about how long a buffer has been dirty, that's kupdate's job. kupdate doesn't care if the buffer it is writing is a good candidate for freeing, that's taken care of elsewhere. The two never need to talk (aside from optimizations).

Quoted 2 lines

I don't see why it makes sense to have both a kupdate and a bdflush thread.

Having two threads is exactly what allows memory pressure to not be concerned about how long a buffer has been dirty.

Quoted 5 lines

Almost ;-) memory pressure doesn't need to care about how long a buffer has been dirty, that's kupdate's job. kupdate doesn't care if the buffer it is writing is a good candidate for freeing, that's taken care of elsewhere. The two never need to talk (aside from optimizations).

My point is, they should talk, in fact they should be the same function. It's never right for bdflush to submit younger buffers when there are dirty buffers whose flush time has already passed.

On Monday, August 06, 2001 09:45:12 PM +0200 Daniel Phillips

Quoted 6 lines · <[email protected]> wrote:

Quoted 5 lines

Almost ;-) memory pressure doesn't need to care about how long a buffer has been dirty, that's kupdate's job. kupdate doesn't care if the buffer it is writing is a good candidate for freeing, that's taken care of elsewhere. The two never need to talk (aside from optimizations).

Quoted 3 lines

My point is, they should talk, in fact they should be the same function. It's never right for bdflush to submit younger buffers when there are dirty buffers whose flush time has already passed.

Grin, we're talking in circles. My point is that by having two threads, bdflush is allowed to skip over older buffers in favor of younger ones because somebody else is responsible for writing the older ones out.

Quoted 9 lines · Stephen C. Tweedie

On Mon, Aug 06, 2001 at 11:18:26PM +0200, Daniel Phillips wrote:
FWIW, we've seen big performance degradations in the past when testing different ext3 checkpointing modes. You can't reuse a disk block in the journal without making sure that the data in it has been flushed to disk, so ext3 does regular checkpointing to flush journaled blocks out. That can interact very badly with normal VM writeback if you're not careful: having two threads doing the same thing at the same time can just thrash the disk.

Quoted 3 lines

Parallel sync() calls from multiple processes has shown up the same behaviour on ext2 in the past. I'd definitely like to see at most one thread of writeback per disk to avoid that.

Why not have a facility with which each fs can register their own writeback functions with a time interval? The daemon would be doing the writing to the device and would be invoking the fs registered writers every <time interval> seconds. That would avoid the problem of having two fs trying to write in parallel but that ignores the problem of having two parallel writers on separate partitions of the same disk but that could be solved at the fs writeback function level.

At least for NTFS TNG I was thinking of having a daemon running every 5 seconds and committing dirty data to disk but it would be iterating over all mounted ntfs volumes in sequence and flushing all dirty data for each, thus avoiding concurrent writing to the same disk, which I had thought might cause a problem and you just confirmed it...[1]

[1] I am aware this probably doesn't scale too well but considering a volume can span several disk partitions on the same disk or across several disks I don't see how to parallelize at the fs level.

One thread per block device; flushes across mounts on the same device are serialized. This model works well for fs->device graphs that are strict trees. For a non-strict tree (acyclic graph) its not clear what to do, but you could argue that such a configuration is stupid, so any kind of punt would do.

Quoted 5 lines · Daniel Phillips

One thread per block device; flushes across mounts on the same device are serialized. This model works well for fs->device graphs that are strict trees. For a non-strict tree (acyclic graph) its not clear what to do, but you could argue that such a configuration is stupid, so any kind of punt would do.

Except that you can have a part of fs structures on a separate device. Journal, for one thing. Now think of two disks, both partitioned. Two filesystems. Each has data on the first partition of its own disk. And journal on the second of another.

Ext3 has its own writeback daemon

Hi,

Quoted 1 line · Daniel Phillips

Ext3 has its own writeback daemon

Ext3 has a daemon to schedule commits to the journal, but it uses the normal IO scheduler for unforced writebacks.

Quoted 5 lines · Stephen C. Tweedie

Quoted 1 line · Daniel Phillips

Ext3 has its own writeback daemon

Ext3 has a daemon to schedule commits to the journal, but it uses the normal IO scheduler for unforced writebacks.

Yes. The currently favored journalling mode uses a writeback journal, no?

Quoted 6 lines

On Monday, August 06, 2001 09:45:12 PM +0200 Daniel Phillips

Grin, we're talking in circles. My point is that by having two threads, bdflush is allowed to skip over older buffers in favor of younger ones because somebody else is responsible for writing the older ones out.

Yes, and you can't imagine an algorithm that could do that with *one* thread?

On Mon, Aug 06, 2001 at 11:18:26PM +0200, Daniel Phillips wrote:
FWIW, we've seen big performance degradations in the past when testing different ext3 checkpointing modes. You can't reuse a disk block in the journal without making sure that the data in it has been flushed to disk, so ext3 does regular checkpointing to flush journaled blocks out. That can interact very badly with normal VM writeback if you're not careful: having two threads doing the same thing at the same time can just thrash the disk.

Parallel sync() calls from multiple processes has shown up the same behaviour on ext2 in the past. I'd definitely like to see at most one thread of writeback per disk to avoid that.

Hi,

Quoted 9 lines · Daniel Phillips

Quoted 6 lines

On Monday, August 06, 2001 09:45:12 PM +0200 Daniel Phillips

Grin, we're talking in circles. My point is that by having two threads, bdflush is allowed to skip over older buffers in favor of younger ones because somebody else is responsible for writing the older ones out.

Yes, and you can't imagine an algorithm that could do that with *one* thread?

FWIW, we've seen big performance degradations in the past when testing different ext3 checkpointing modes. You can't reuse a disk block in the journal without making sure that the data in it has been flushed to disk, so ext3 does regular checkpointing to flush journaled blocks out. That can interact very badly with normal VM writeback if you're not careful: having two threads doing the same thing at the same time can just thrash the disk.

Parallel sync() calls from multiple processes has shown up the same behaviour on ext2 in the past. I'd definitely like to see at most one thread of writeback per disk to avoid that.

Quoted 9 lines · Stephen C. Tweedie

On Mon, Aug 06, 2001 at 11:18:26PM +0200, Daniel Phillips wrote:
FWIW, we've seen big performance degradations in the past when testing different ext3 checkpointing modes. You can't reuse a disk block in the journal without making sure that the data in it has been flushed to disk, so ext3 does regular checkpointing to flush journaled blocks out. That can interact very badly with normal VM writeback if you're not careful: having two threads doing the same thing at the same time can just thrash the disk.

Quoted 3 lines

Parallel sync() calls from multiple processes has shown up the same behaviour on ext2 in the past. I'd definitely like to see at most one thread of writeback per disk to avoid that.

Be carefull here. I have a system (solaris) at the office that has 96 drives on it. Do we really want 96 writeback threads? With 96 drives, suspect the bus bandwidth would be the limiting factor.

Quoted 19 lines · Stephen C. Tweedie

Quoted 9 lines · Daniel Phillips

Quoted 6 lines

On Monday, August 06, 2001 09:45:12 PM +0200 Daniel Phillips

Grin, we're talking in circles. My point is that by having two threads, bdflush is allowed to skip over older buffers in favor of younger ones because somebody else is responsible for writing the older ones out.

Yes, and you can't imagine an algorithm that could do that with *one* thread?

FWIW, we've seen big performance degradations in the past when testing different ext3 checkpointing modes. You can't reuse a disk block in the journal without making sure that the data in it has been flushed to disk, so ext3 does regular checkpointing to flush journaled blocks out. That can interact very badly with normal VM writeback if you're not careful: having two threads doing the same thing at the same time can just thrash the disk.

Quoted 3 lines

Parallel sync() calls from multiple processes has shown up the same behaviour on ext2 in the past. I'd definitely like to see at most one thread of writeback per disk to avoid that.

Be carefull here. I have a system (solaris) at the office that has 96 drives on it. Do we really want 96 writeback threads? With 96 drives, suspect the bus bandwidth would be the limiting factor.

Quoted 5 lines · On Wednesday, August 01, 2001 04:57:35 PM +0200 Daniel Phillips…

Quoted 3 lines · Chris Mason

This has been tested a little more now, both ext2 (1k, 4k) and reiserfs. dbench and iozone testing don't show any difference, but I need to spend a little more time on the benchmarks.

Quoted 2 lines

It's impressive that such seemingly radical surgery on the vm innards is a) possible and b) doesn't make the system perform noticably worse.

radical surgery is always possible ;-) But, I was expecting better performance results than I got. I'm trying a few other things out here, more details will come if they work.