On Fri, Jan 18, 2008 at 01:41:33PM +0800, Fengguang Wu wrote:
> > That is, think of large file writes like process scheduler batch
> > jobs - bulk throughput is what matters, so the larger the time slice
> > you give them the higher the throughput.
> >
> > IMO, the sort of result we should be look
On Thu, Jan 17, 2008 at 10:43:15PM -0800, Michael Rubin wrote:
> On Jan 17, 2008 8:56 PM, Fengguang Wu <[EMAIL PROTECTED]> wrote:
> > On Thu, Jan 17, 2008 at 01:07:05PM -0800, Michael Rubin wrote:
> > Suppose we want to grant longer expiration window for temp files,
> > adding a new list named s_di
On Jan 18, 2008 12:54 AM, David Chinner <[EMAIL PROTECTED]> wrote:
> At this point, I'd say it is best to leave it to the filesystem and
> the elevator to do their jobs properly.
Amen.
mrubin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
On Thu, Jan 17, 2008 at 09:38:24PM -0800, Michael Rubin wrote:
> On Jan 17, 2008 9:01 PM, David Chinner <[EMAIL PROTECTED]> wrote:
>
> First off thank you for the very detailed reply. This rocks and gives
> me much to think about.
>
> > On Thu, Jan 17, 2008 at 01:07:05PM -0800, Michael Rubin wrot
On Fri, Jan 18, 2008 at 06:41:09AM +0100, Andi Kleen wrote:
> Fengguang Wu <[EMAIL PROTECTED]> writes:
> >
> > Suppose we want to grant longer expiration window for temp files,
> > adding a new list named s_dirty_tmpfile would be a handy solution.
>
> How would the kernel know that a file is a tmp
We have some code internally that does just this, though it slightly
abuses struct page by tagging pages with the highest priority that
dirties them.
I'm not sure what a better solution is, though there has been talk about
rewritting it to use a per mapping radix tree to keep mem_map small.
Fengguang Wu wrote:
On Tue, Jan 15, 2008 at 09:51:49PM -0800, Andrew Morton wrote:
On Wed, 16 Jan 2008 12:55:07 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
On Tue, Jan 15, 2008 at 08:42:36PM -0800, Andrew Morton wrote:
On Wed, 16 Jan 2008 12:25:53 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrot
On Jan 17, 2008 8:56 PM, Fengguang Wu <[EMAIL PROTECTED]> wrote:
Once again thanks for the speedy replies. :-)
> On Thu, Jan 17, 2008 at 01:07:05PM -0800, Michael Rubin wrote:
> Suppose we want to grant longer expiration window for temp files,
> adding a new list named s_dirty_tmpfile would be a
> Fairness is a tradeoff between seeks and bandwidth. Ideally, we
> want to spend 50% of the *disk* time servicing sequential writes and
> 50% of the time servicing seeky writes - that way neither get
> penalised unfairly by the other type of workload.
>
> Switching inodes during writeback implie
Fengguang Wu <[EMAIL PROTECTED]> writes:
>
> Suppose we want to grant longer expiration window for temp files,
> adding a new list named s_dirty_tmpfile would be a handy solution.
How would the kernel know that a file is a tmp file?
> So the question is: should we need more than 3 QoS classes?
[
On Jan 17, 2008 9:01 PM, David Chinner <[EMAIL PROTECTED]> wrote:
First off thank you for the very detailed reply. This rocks and gives
me much to think about.
> On Thu, Jan 17, 2008 at 01:07:05PM -0800, Michael Rubin wrote:
> This seems suboptimal for large files. If you keep feeding in
> new le
On Thu, Jan 17, 2008 at 01:07:05PM -0800, Michael Rubin wrote:
> > Michael, could you sort out and document the new starvation prevention
> > schemes?
>
> The basic idea behind the writeback algorithm to handle starvation.
> The over arching idea is that we want to preserve order of writeback
> b
On Thu, Jan 17, 2008 at 01:07:05PM -0800, Michael Rubin wrote:
> On Jan 17, 2008 1:41 AM, Fengguang Wu <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 15, 2008 at 12:09:21AM -0800, Michael Rubin wrote:
> > The main benefit of rbtree is possibly better support of future policies.
> > Can you demonstrate
On Jan 17, 2008 1:41 AM, Fengguang Wu <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 15, 2008 at 12:09:21AM -0800, Michael Rubin wrote:
> The main benefit of rbtree is possibly better support of future policies.
> Can you demonstrate an example?
These are ill-formed thoughts as of now on my end but the
On Tue, Jan 15, 2008 at 12:09:21AM -0800, Michael Rubin wrote:
> 1) Adding a datastructure to guarantee fairness when writing
>inodes to disk and simplify the code base.
>
>When inodes are parked for writeback they are parked in the
>flush_tree. The flush tree is a data structure based
On Thu, Jan 17, 2008 at 11:16:00AM +0800, Fengguang Wu wrote:
> On Thu, Jan 17, 2008 at 09:35:10AM +1100, David Chinner wrote:
> > On Wed, Jan 16, 2008 at 05:07:20PM +0800, Fengguang Wu wrote:
> > > On Tue, Jan 15, 2008 at 09:51:49PM -0800, Andrew Morton wrote:
> > > > > Then to do better ordering
On Wed, Jan 16, 2008 at 10:55:28AM -0800, Michael Rubin wrote:
> On Jan 15, 2008 7:01 PM, Fengguang Wu <[EMAIL PROTECTED]> wrote:
> > Basically I think rbtree is an overkill to do time based ordering.
> > Sorry, Michael. But s_dirty would be enough for that. Plus, s_more_io
> > provides fair queuin
On Thu, Jan 17, 2008 at 09:35:10AM +1100, David Chinner wrote:
> On Wed, Jan 16, 2008 at 05:07:20PM +0800, Fengguang Wu wrote:
> > On Tue, Jan 15, 2008 at 09:51:49PM -0800, Andrew Morton wrote:
> > > > Then to do better ordering by adopting radix tree(or rbtree
> > > > if radix tree is not enough),
On Wed, Jan 16, 2008 at 05:07:20PM +0800, Fengguang Wu wrote:
> On Tue, Jan 15, 2008 at 09:51:49PM -0800, Andrew Morton wrote:
> > > Then to do better ordering by adopting radix tree(or rbtree
> > > if radix tree is not enough),
> >
> > ordering of what?
>
> Switch from time to location.
Note th
On Jan 15, 2008 7:01 PM, Fengguang Wu <[EMAIL PROTECTED]> wrote:
> Basically I think rbtree is an overkill to do time based ordering.
> Sorry, Michael. But s_dirty would be enough for that. Plus, s_more_io
> provides fair queuing between small/large files, and s_more_io_wait
> provides waiting mech
On Wed, Jan 16, 2008 at 12:13:43AM -0800, Andrew Morton wrote:
> On Wed, 16 Jan 2008 18:55:38 +1100 David Chinner <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Jan 15, 2008 at 07:44:15PM -0800, Andrew Morton wrote:
> > > On Wed, 16 Jan 2008 11:01:08 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> > >
On Tue, Jan 15, 2008 at 09:51:49PM -0800, Andrew Morton wrote:
> On Wed, 16 Jan 2008 12:55:07 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Jan 15, 2008 at 08:42:36PM -0800, Andrew Morton wrote:
> > > On Wed, 16 Jan 2008 12:25:53 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> > >
>
On Wed, 16 Jan 2008 18:55:38 +1100 David Chinner <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 15, 2008 at 07:44:15PM -0800, Andrew Morton wrote:
> > On Wed, 16 Jan 2008 11:01:08 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Jan 15, 2008 at 09:53:42AM -0800, Michael Rubin wrote:
> >
On Tue, Jan 15, 2008 at 07:44:15PM -0800, Andrew Morton wrote:
> On Wed, 16 Jan 2008 11:01:08 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Jan 15, 2008 at 09:53:42AM -0800, Michael Rubin wrote:
> > > On Jan 15, 2008 12:46 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > > > Just a
On Wed, 16 Jan 2008 12:55:07 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 15, 2008 at 08:42:36PM -0800, Andrew Morton wrote:
> > On Wed, 16 Jan 2008 12:25:53 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> >
> > > list_heads are OK if we use them for one and only function.
> >
> >
On Tue, Jan 15, 2008 at 08:42:36PM -0800, Andrew Morton wrote:
> On Wed, 16 Jan 2008 12:25:53 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
>
> > list_heads are OK if we use them for one and only function.
>
> Not really. They're inappropriate when you wish to remember your
> position in the lis
On Wed, 16 Jan 2008 12:25:53 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> list_heads are OK if we use them for one and only function.
Not really. They're inappropriate when you wish to remember your
position in the list while you dropped the lock (as we must do in
writeback).
A data structur
On Tue, Jan 15, 2008 at 07:44:15PM -0800, Andrew Morton wrote:
> On Wed, 16 Jan 2008 11:01:08 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Jan 15, 2008 at 09:53:42AM -0800, Michael Rubin wrote:
> > > On Jan 15, 2008 12:46 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > > > Just a
On Wed, 16 Jan 2008 11:01:08 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 15, 2008 at 09:53:42AM -0800, Michael Rubin wrote:
> > On Jan 15, 2008 12:46 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > > Just a quick question, how does this interact/depend-uppon etc.. with
> > > Feng
On Tue, Jan 15, 2008 at 09:53:42AM -0800, Michael Rubin wrote:
> On Jan 15, 2008 12:46 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > Just a quick question, how does this interact/depend-uppon etc.. with
> > Fengguangs patches I still have in my mailbox? (Those from Dec 28th)
>
> They don't. Th
On Jan 15, 2008 12:46 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Just a quick question, how does this interact/depend-uppon etc.. with
> Fengguangs patches I still have in my mailbox? (Those from Dec 28th)
They don't. They apply to a 2.6.24rc7 tree. This is a candidte for 2.6.25.
This work w
On Tue, 2008-01-15 at 00:09 -0800, Michael Rubin wrote:
> From: Michael Rubin <[EMAIL PROTECTED]>
>
> For those of you who have waited so long. This is the third submission
> of the first attempt at this patch. It is a trilogy.
Just a quick question, how does this interact/depend-uppon etc.. wit
From: Michael Rubin <[EMAIL PROTECTED]>
For those of you who have waited so long. This is the third submission
of the first attempt at this patch. It is a trilogy.
Two changes are in this patch. They are dependant on each other.
In addition we get an unintended performance improvement. Syncing
1
From: Michael Rubin <[EMAIL PROTECTED]>
This is an attempt to unify the writeback data structures. By adding an
rb tree we are able to have one consistent time ordering mechanism for
writeback. This should aid debugging and allow for future work with more
sophisticated time ordering methods. This
34 matches
Mail list logo
