From: "John Stoffel" <john@stoffel.org> To: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, miklos@szeredi.hu, akpm@linux-foundation.org, neilb@suse.de, dgc@sgi.com, tomoki.sekiyama.qu@hitachi.com, nikita@clusterfs.com, trond.myklebust@fys.uio.no, yingchao.zhou@gmail.com, richard@rsk.demon.co.uk, torvalds@linux-foundation.org Subject: Re: [PATCH 00/23] per device dirty throttling -v10 Date: Tue, 11 Sep 2007 22:31:32 -0400 [thread overview] Message-ID: <18151.20356.862163.430265@stoffel.org> (raw) In-Reply-To: <20070911195350.825778000@chello.nl> Peter> Per device dirty throttling patches These patches aim to Peter> improve balance_dirty_pages() and directly address three Peter> issues: Peter> 1) inter device starvation Peter> 2) stacked device deadlocks Peter> 3) inter process starvation Peter> 1 and 2 are a direct result from removing the global dirty Peter> limit and using per device dirty limits. By giving each device Peter> its own dirty limit is will no longer starve another device, Peter> and the cyclic dependancy on the dirty limit is broken. Ye haa! This should be a big improvement. Peter> In order to efficiently distribute the dirty limit across the Peter> independant devices a floating proportion is used, this will Peter> allocate a share of the total limit proportional to the Peter> device's recent activity. I'm not sure I like or agree with this. Shouldn't we be limiting based on the device's capability to sustain traffic? So if I have a RAID device which can read/write a total of 100Mb/sec, while at the same time I've got a CF device which can do 5Mb/sec, shouldn't we be more strongly limiting the CF device, even if it is the only device being written to? Of course, I haven't read the patches yet, nor am I qualified to comment on them in any meanginful way I think. Hopefully I'm just missing something key here in the explanation. Peter> 3 is done by also scaling the dirty limit proportional to the Peter> current task's recent dirty rate. Do you mean task or device here? I'm just wondering how well this works with a bunch of devices with wildly varying speeds. John
WARNING: multiple messages have this Message-ID (diff)
From: "John Stoffel" <john@stoffel.org> To: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, miklos@szeredi.hu, akpm@linux-foundation.org, neilb@suse.de, dgc@sgi.com, tomoki.sekiyama.qu@hitachi.com, nikita@clusterfs.com, trond.myklebust@fys.uio.no, yingchao.zhou@gmail.com, richard@rsk.demon.co.uk, torvalds@linux-foundation.org Subject: Re: [PATCH 00/23] per device dirty throttling -v10 Date: Tue, 11 Sep 2007 22:31:32 -0400 [thread overview] Message-ID: <18151.20356.862163.430265@stoffel.org> (raw) In-Reply-To: <20070911195350.825778000@chello.nl> Peter> Per device dirty throttling patches These patches aim to Peter> improve balance_dirty_pages() and directly address three Peter> issues: Peter> 1) inter device starvation Peter> 2) stacked device deadlocks Peter> 3) inter process starvation Peter> 1 and 2 are a direct result from removing the global dirty Peter> limit and using per device dirty limits. By giving each device Peter> its own dirty limit is will no longer starve another device, Peter> and the cyclic dependancy on the dirty limit is broken. Ye haa! This should be a big improvement. Peter> In order to efficiently distribute the dirty limit across the Peter> independant devices a floating proportion is used, this will Peter> allocate a share of the total limit proportional to the Peter> device's recent activity. I'm not sure I like or agree with this. Shouldn't we be limiting based on the device's capability to sustain traffic? So if I have a RAID device which can read/write a total of 100Mb/sec, while at the same time I've got a CF device which can do 5Mb/sec, shouldn't we be more strongly limiting the CF device, even if it is the only device being written to? Of course, I haven't read the patches yet, nor am I qualified to comment on them in any meanginful way I think. Hopefully I'm just missing something key here in the explanation. Peter> 3 is done by also scaling the dirty limit proportional to the Peter> current task's recent dirty rate. Do you mean task or device here? I'm just wondering how well this works with a bunch of devices with wildly varying speeds. John -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-09-12 2:32 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-09-11 19:53 [PATCH 00/23] per device dirty throttling -v10 Peter Zijlstra 2007-09-11 19:53 ` Peter Zijlstra 2007-09-11 19:53 ` [PATCH 01/23] nfs: remove congestion_end() Peter Zijlstra 2007-09-11 19:53 ` Peter Zijlstra 2007-09-11 19:53 ` [PATCH 02/23] lib: percpu_counter_add Peter Zijlstra 2007-09-11 19:53 ` Peter Zijlstra 2007-09-11 19:53 ` [PATCH 03/23] lib: percpu_counter_sub Peter Zijlstra 2007-09-11 19:53 ` Peter Zijlstra 2007-09-11 19:53 ` [PATCH 04/23] lib: percpu_counter variable batch Peter Zijlstra 2007-09-11 19:53 ` Peter Zijlstra 2007-09-11 19:53 ` [PATCH 05/23] lib: make percpu_counter_add take s64 Peter Zijlstra 2007-09-11 19:53 ` Peter Zijlstra 2007-09-11 19:53 ` [PATCH 06/23] lib: percpu_counter_set Peter Zijlstra 2007-09-11 19:53 ` Peter Zijlstra 2007-09-11 19:53 ` [PATCH 07/23] lib: percpu_counter_sum_positive Peter Zijlstra 2007-09-11 19:53 ` Peter Zijlstra 2007-09-11 19:53 ` [PATCH 08/23] lib: percpu_count_sum() Peter Zijlstra 2007-09-11 19:53 ` Peter Zijlstra 2007-09-11 19:53 ` [PATCH 09/23] lib: percpu_counter_init error handling Peter Zijlstra 2007-09-11 19:53 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 10/23] lib: percpu_counter_init_irq Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 11/23] mm: bdi init hooks Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 12/23] containers: " Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 13/23] mtd: " Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 14/23] mtd: clean up the backing_dev_info usage Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 15/23] mtd: give mtdconcat devices their own backing_dev_info Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 16/23] mm: scalable bdi statistics counters Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 17/23] mm: count reclaimable pages per BDI Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 18/23] mm: count writeback " Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 19/23] mm: expose BDI statistics in sysfs Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 20/23] lib: floating proportions Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 21/23] mm: per device dirty threshold Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-12 2:36 ` John Stoffel 2007-09-12 2:36 ` John Stoffel 2007-09-12 8:45 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 22/23] mm: dirty balancing for tasks Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-11 19:54 ` [PATCH 23/23] debug: sysfs files for the current ratio/size/total Peter Zijlstra 2007-09-11 19:54 ` Peter Zijlstra 2007-09-12 2:31 ` John Stoffel [this message] 2007-09-12 2:31 ` [PATCH 00/23] per device dirty throttling -v10 John Stoffel 2007-09-12 9:00 ` Peter Zijlstra 2007-09-13 23:13 Tobias Oetiker
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=18151.20356.862163.430265@stoffel.org \ --to=john@stoffel.org \ --cc=a.p.zijlstra@chello.nl \ --cc=akpm@linux-foundation.org \ --cc=dgc@sgi.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=miklos@szeredi.hu \ --cc=neilb@suse.de \ --cc=nikita@clusterfs.com \ --cc=richard@rsk.demon.co.uk \ --cc=tomoki.sekiyama.qu@hitachi.com \ --cc=torvalds@linux-foundation.org \ --cc=trond.myklebust@fys.uio.no \ --cc=yingchao.zhou@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.