[LSF/MM TOPIC] Writeback - current state and future

[LSF/MM TOPIC] Writeback - current state and future

[Jan Kara]

  Hi,

  I'd like to have one session about writeback. The content would highly
depend on the current state of things but on a general level, I'd like to
quickly sum up what went into the kernel (or is mostly ready to go) since
last LSF (handling of background writeback, livelock avoidance), what is
being worked on - IO-less balance_dirty_pages() (if it won't be in the
mostly done section), what other things need to be improved (kswapd
writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

[LSF/MM TOPIC] Writeback - current state and future

[Jan Kara]

  Hi,

  I'd like to have one session about writeback. The content would highly
depend on the current state of things but on a general level, I'd like to
quickly sum up what went into the kernel (or is mostly ready to go) since
last LSF (handling of background writeback, livelock avoidance), what is
being worked on - IO-less balance_dirty_pages() (if it won't be in the
mostly done section), what other things need to be improved (kswapd
writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] Writeback - current state and future

[Curt Wohlgemuth]

I think it would also be valuable to include a discussion of writeback
testing, so perhaps we can go beyond simply large numbers of dd
processes.

On Fri, Feb 4, 2011 at 8:42 AM, Jan Kara <jack@suse.cz> wrote:
>  Hi,
>
>  I'd like to have one session about writeback. The content would highly
> depend on the current state of things but on a general level, I'd like to
> quickly sum up what went into the kernel (or is mostly ready to go) since
> last LSF (handling of background writeback, livelock avoidance), what is
> being worked on - IO-less balance_dirty_pages() (if it won't be in the
> mostly done section), what other things need to be improved (kswapd
> writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)
>
>                                                                Honza
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [LSF/MM TOPIC] Writeback - current state and future

[Curt Wohlgemuth]

I think it would also be valuable to include a discussion of writeback
testing, so perhaps we can go beyond simply large numbers of dd
processes.

On Fri, Feb 4, 2011 at 8:42 AM, Jan Kara <jack@suse.cz> wrote:
>  Hi,
>
>  I'd like to have one session about writeback. The content would highly
> depend on the current state of things but on a general level, I'd like to
> quickly sum up what went into the kernel (or is mostly ready to go) since
> last LSF (handling of background writeback, livelock avoidance), what is
> being worked on - IO-less balance_dirty_pages() (if it won't be in the
> mostly done section), what other things need to be improved (kswapd
> writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)
>
>                                                                Honza
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] Writeback - current state and future

[Tao Ma]

On 02/05/2011 02:06 AM, Curt Wohlgemuth wrote:
> I think it would also be valuable to include a discussion of writeback
> testing, so perhaps we can go beyond simply large numbers of dd
> processes.
>    
yeah, I guess a good test case is really needed here.
We are trying to use the new writeback, but can't find some good test 
cases that t can be used.
A good number is always needed when we prompt new kernel features to my 
employer. ;)

Regards,
Tao
> On Fri, Feb 4, 2011 at 8:42 AM, Jan Kara<jack@suse.cz>  wrote:
>    
>>   Hi,
>>
>>   I'd like to have one session about writeback. The content would highly
>> depend on the current state of things but on a general level, I'd like to
>> quickly sum up what went into the kernel (or is mostly ready to go) since
>> last LSF (handling of background writeback, livelock avoidance), what is
>> being worked on - IO-less balance_dirty_pages() (if it won't be in the
>> mostly done section), what other things need to be improved (kswapd
>> writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)
>>
>>                                                                 Honza
>> --
>> Jan Kara<jack@suse.cz>
>> SUSE Labs, CR
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>      
> --
> 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/ .
> Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
> Don't email:<a href=ilto:"dont@kvack.org">  email@kvack.org</a>
>    

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] Writeback - current state and future

[Boaz Harrosh]

On 02/04/2011 06:42 PM, Jan Kara wrote:
>   Hi,
> 
>   I'd like to have one session about writeback. The content would highly
> depend on the current state of things but on a general level, I'd like to
> quickly sum up what went into the kernel (or is mostly ready to go) since
> last LSF (handling of background writeback, livelock avoidance), what is
> being worked on - IO-less balance_dirty_pages() (if it won't be in the
> mostly done section), what other things need to be improved (kswapd
> writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)
> 
> 								Honza

Ha, I most certainly want to participate in this talk. I wanted to
suggest it myself.

Topics that I would like to raise on the matter.

[IO-less balance_dirty_pages]
As said, I'd really like if Wu or Jan could explain more about the math
and IO patterns that went into this tremendous work, and how it should
affect us fs maintainers in means of advantages and disadvantages. If
digging too deeply into this is not interesting for every body, perhaps
a side meeting with fewer people is also possible.

[Aligned write-back]
I have just finished raid5/6 support in my filesystem and will be sending
a patch that tries very aggressively to align IO on stripe boundaries.
I did not take the btrfs way of cut/paste of the write_cache_pages() function
to better fit the bill. I used the wbc->nr_to_write to trim down IO on stripe
alignment. Together with some internal structure games, I now have a much
better situation then untouched code. Better I mean that if I have simple
linear dd IO on a file, I can see o(90%) aligned IOs as opposed to 20% before
that patch. The only remaining issue, I think I have not fully investigated
it yet, is that: because I do not want any residues left from outside the
writepages() call so I do not need to sync and lock with flush, and have a
"flushing" flag in my writeout path. So what I still get is that sometimes
the writeback is able to catch up with dd and I get short writes at the
reminder, which makes the end of this call and the start of the next call
unaligned.

I envision a simple BDI members just like ra_pages for readahead that better
govern the writeback chunking. (And is accounted for in the fairness).

[Smarter/more cache eviction patterns]
I love it when I do a simple dd test in a UML (300Mg of ram) and half way down
I get these fat WARN_ONs of the iscsi tcp writeback failing to allocate network
buffers. And I did lower the writeback ratio a lot because the default of 20% does
not work for a long time, like since 35 or 36. The UML is not the only affected
system any low-memory embedded-like but 64 bit system would be. Now the IO does
complete eventually but the performance is down to 20%.

Now for a dd or cp like work pattern I would like the pages be freed much more
aggressively, like right after IO completion because I most certainly will not
use them again. On the other side git for example will write a big sequential
file then immediately turn and read it, so cache presence is a win. But I think
we can still come up with good patterns that take into account the number of
fileh opened on an inode, and some hot inode history to come up with better
patterns. (Some of this history we already have with the security plugins)

And there are other topics that I had, but can remember right now.

Thanks
Boaz

Re: [LSF/MM TOPIC] Writeback - current state and future

[Boaz Harrosh]

On 02/04/2011 06:42 PM, Jan Kara wrote:
>   Hi,
> 
>   I'd like to have one session about writeback. The content would highly
> depend on the current state of things but on a general level, I'd like to
> quickly sum up what went into the kernel (or is mostly ready to go) since
> last LSF (handling of background writeback, livelock avoidance), what is
> being worked on - IO-less balance_dirty_pages() (if it won't be in the
> mostly done section), what other things need to be improved (kswapd
> writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)
> 
> 								Honza

Ha, I most certainly want to participate in this talk. I wanted to
suggest it myself.

Topics that I would like to raise on the matter.

[IO-less balance_dirty_pages]
As said, I'd really like if Wu or Jan could explain more about the math
and IO patterns that went into this tremendous work, and how it should
affect us fs maintainers in means of advantages and disadvantages. If
digging too deeply into this is not interesting for every body, perhaps
a side meeting with fewer people is also possible.

[Aligned write-back]
I have just finished raid5/6 support in my filesystem and will be sending
a patch that tries very aggressively to align IO on stripe boundaries.
I did not take the btrfs way of cut/paste of the write_cache_pages() function
to better fit the bill. I used the wbc->nr_to_write to trim down IO on stripe
alignment. Together with some internal structure games, I now have a much
better situation then untouched code. Better I mean that if I have simple
linear dd IO on a file, I can see o(90%) aligned IOs as opposed to 20% before
that patch. The only remaining issue, I think I have not fully investigated
it yet, is that: because I do not want any residues left from outside the
writepages() call so I do not need to sync and lock with flush, and have a
"flushing" flag in my writeout path. So what I still get is that sometimes
the writeback is able to catch up with dd and I get short writes at the
reminder, which makes the end of this call and the start of the next call
unaligned.

I envision a simple BDI members just like ra_pages for readahead that better
govern the writeback chunking. (And is accounted for in the fairness).

[Smarter/more cache eviction patterns]
I love it when I do a simple dd test in a UML (300Mg of ram) and half way down
I get these fat WARN_ONs of the iscsi tcp writeback failing to allocate network
buffers. And I did lower the writeback ratio a lot because the default of 20% does
not work for a long time, like since 35 or 36. The UML is not the only affected
system any low-memory embedded-like but 64 bit system would be. Now the IO does
complete eventually but the performance is down to 20%.

Now for a dd or cp like work pattern I would like the pages be freed much more
aggressively, like right after IO completion because I most certainly will not
use them again. On the other side git for example will write a big sequential
file then immediately turn and read it, so cache presence is a win. But I think
we can still come up with good patterns that take into account the number of
fileh opened on an inode, and some hot inode history to come up with better
patterns. (Some of this history we already have with the security plugins)

And there are other topics that I had, but can remember right now.

Thanks
Boaz

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] Writeback - current state and future

[Sorin Faibish]

I was thinking to have a special track for all the writeback related  
topics.
I would like also to include a discussion on new cache writeback paterns
with the target to prevent any cache swaps that are becoming a bigger  
problem
when dealing with servers wir 100's GB caches. The swap is the worst that
could happen to the performance of such systems. I will share my latest  
findings
in the cache writeback in continuation to my previous discussion at last  
LSF.

/Sorin

On Sun, 06 Feb 2011 05:43:20 -0500, Boaz Harrosh <bharrosh@panasas.com>  
wrote:

> On 02/04/2011 06:42 PM, Jan Kara wrote:
>>   Hi,
>>
>>   I'd like to have one session about writeback. The content would highly
>> depend on the current state of things but on a general level, I'd like  
>> to
>> quickly sum up what went into the kernel (or is mostly ready to go)  
>> since
>> last LSF (handling of background writeback, livelock avoidance), what is
>> being worked on - IO-less balance_dirty_pages() (if it won't be in the
>> mostly done section), what other things need to be improved (kswapd
>> writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)
>>
>> 								Honza
>
> Ha, I most certainly want to participate in this talk. I wanted to
> suggest it myself.
>
> Topics that I would like to raise on the matter.
>
> [IO-less balance_dirty_pages]
> As said, I'd really like if Wu or Jan could explain more about the math
> and IO patterns that went into this tremendous work, and how it should
> affect us fs maintainers in means of advantages and disadvantages. If
> digging too deeply into this is not interesting for every body, perhaps
> a side meeting with fewer people is also possible.
>
> [Aligned write-back]
> I have just finished raid5/6 support in my filesystem and will be sending
> a patch that tries very aggressively to align IO on stripe boundaries.
> I did not take the btrfs way of cut/paste of the write_cache_pages()  
> function
> to better fit the bill. I used the wbc->nr_to_write to trim down IO on  
> stripe
> alignment. Together with some internal structure games, I now have a much
> better situation then untouched code. Better I mean that if I have simple
> linear dd IO on a file, I can see o(90%) aligned IOs as opposed to 20%  
> before
> that patch. The only remaining issue, I think I have not fully  
> investigated
> it yet, is that: because I do not want any residues left from outside the
> writepages() call so I do not need to sync and lock with flush, and have  
> a
> "flushing" flag in my writeout path. So what I still get is that  
> sometimes
> the writeback is able to catch up with dd and I get short writes at the
> reminder, which makes the end of this call and the start of the next call
> unaligned.
>
> I envision a simple BDI members just like ra_pages for readahead that  
> better
> govern the writeback chunking. (And is accounted for in the fairness).
>
> [Smarter/more cache eviction patterns]
> I love it when I do a simple dd test in a UML (300Mg of ram) and half  
> way down
> I get these fat WARN_ONs of the iscsi tcp writeback failing to allocate  
> network
> buffers. And I did lower the writeback ratio a lot because the default  
> of 20% does
> not work for a long time, like since 35 or 36. The UML is not the only  
> affected
> system any low-memory embedded-like but 64 bit system would be. Now the  
> IO does
> complete eventually but the performance is down to 20%.
>
> Now for a dd or cp like work pattern I would like the pages be freed  
> much more
> aggressively, like right after IO completion because I most certainly  
> will not
> use them again. On the other side git for example will write a big  
> sequential
> file then immediately turn and read it, so cache presence is a win. But  
> I think
> we can still come up with good patterns that take into account the  
> number of
> fileh opened on an inode, and some hot inode history to come up with  
> better
> patterns. (Some of this history we already have with the security  
> plugins)
>
> And there are other topics that I had, but can remember right now.
>
> Thanks
> Boaz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"  
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Best Regards
Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division

        EMC²
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : sfaibish@emc.com

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] Writeback - current state and future

[Sorin Faibish]

I was thinking to have a special track for all the writeback related  
topics.
I would like also to include a discussion on new cache writeback paterns
with the target to prevent any cache swaps that are becoming a bigger  
problem
when dealing with servers wir 100's GB caches. The swap is the worst that
could happen to the performance of such systems. I will share my latest  
findings
in the cache writeback in continuation to my previous discussion at last  
LSF.

/Sorin

On Sun, 06 Feb 2011 05:43:20 -0500, Boaz Harrosh <bharrosh@panasas.com>  
wrote:

> On 02/04/2011 06:42 PM, Jan Kara wrote:
>>   Hi,
>>
>>   I'd like to have one session about writeback. The content would highly
>> depend on the current state of things but on a general level, I'd like  
>> to
>> quickly sum up what went into the kernel (or is mostly ready to go)  
>> since
>> last LSF (handling of background writeback, livelock avoidance), what is
>> being worked on - IO-less balance_dirty_pages() (if it won't be in the
>> mostly done section), what other things need to be improved (kswapd
>> writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)
>>
>> 								Honza
>
> Ha, I most certainly want to participate in this talk. I wanted to
> suggest it myself.
>
> Topics that I would like to raise on the matter.
>
> [IO-less balance_dirty_pages]
> As said, I'd really like if Wu or Jan could explain more about the math
> and IO patterns that went into this tremendous work, and how it should
> affect us fs maintainers in means of advantages and disadvantages. If
> digging too deeply into this is not interesting for every body, perhaps
> a side meeting with fewer people is also possible.
>
> [Aligned write-back]
> I have just finished raid5/6 support in my filesystem and will be sending
> a patch that tries very aggressively to align IO on stripe boundaries.
> I did not take the btrfs way of cut/paste of the write_cache_pages()  
> function
> to better fit the bill. I used the wbc->nr_to_write to trim down IO on  
> stripe
> alignment. Together with some internal structure games, I now have a much
> better situation then untouched code. Better I mean that if I have simple
> linear dd IO on a file, I can see o(90%) aligned IOs as opposed to 20%  
> before
> that patch. The only remaining issue, I think I have not fully  
> investigated
> it yet, is that: because I do not want any residues left from outside the
> writepages() call so I do not need to sync and lock with flush, and have  
> a
> "flushing" flag in my writeout path. So what I still get is that  
> sometimes
> the writeback is able to catch up with dd and I get short writes at the
> reminder, which makes the end of this call and the start of the next call
> unaligned.
>
> I envision a simple BDI members just like ra_pages for readahead that  
> better
> govern the writeback chunking. (And is accounted for in the fairness).
>
> [Smarter/more cache eviction patterns]
> I love it when I do a simple dd test in a UML (300Mg of ram) and half  
> way down
> I get these fat WARN_ONs of the iscsi tcp writeback failing to allocate  
> network
> buffers. And I did lower the writeback ratio a lot because the default  
> of 20% does
> not work for a long time, like since 35 or 36. The UML is not the only  
> affected
> system any low-memory embedded-like but 64 bit system would be. Now the  
> IO does
> complete eventually but the performance is down to 20%.
>
> Now for a dd or cp like work pattern I would like the pages be freed  
> much more
> aggressively, like right after IO completion because I most certainly  
> will not
> use them again. On the other side git for example will write a big  
> sequential
> file then immediately turn and read it, so cache presence is a win. But  
> I think
> we can still come up with good patterns that take into account the  
> number of
> fileh opened on an inode, and some hot inode history to come up with  
> better
> patterns. (Some of this history we already have with the security  
> plugins)
>
> And there are other topics that I had, but can remember right now.
>
> Thanks
> Boaz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"  
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Best Regards
Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division

        EMC2
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : sfaibish@emc.com

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] Writeback - current state and future

[Boaz Harrosh]

On 02/06/2011 05:13 PM, Sorin Faibish wrote:
> I was thinking to have a special track for all the writeback related  
> topics.
> I would like also to include a discussion on new cache writeback paterns
> with the target to prevent any cache swaps that are becoming a bigger  
> problem
> when dealing with servers wir 100's GB caches. The swap is the worst that
> could happen to the performance of such systems. I will share my latest  
> findings
> in the cache writeback in continuation to my previous discussion at last  
> LSF.
> 
> /Sorin
> 

Yes, you should try out Wu Fengguang's Latest patches, they fix lots of
what you described in last LSF, and with similar philosophy to what we
talked about. Definitely interesting to see results.

Thanks
Boaz

> On Sun, 06 Feb 2011 05:43:20 -0500, Boaz Harrosh <bharrosh@panasas.com>  
> wrote:
> 
>> On 02/04/2011 06:42 PM, Jan Kara wrote:
>>>   Hi,
>>>
>>>   I'd like to have one session about writeback. The content would highly
>>> depend on the current state of things but on a general level, I'd like  
>>> to
>>> quickly sum up what went into the kernel (or is mostly ready to go)  
>>> since
>>> last LSF (handling of background writeback, livelock avoidance), what is
>>> being worked on - IO-less balance_dirty_pages() (if it won't be in the
>>> mostly done section), what other things need to be improved (kswapd
>>> writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)
>>>
>>> 								Honza
>>
>> Ha, I most certainly want to participate in this talk. I wanted to
>> suggest it myself.
>>
>> Topics that I would like to raise on the matter.
>>
>> [IO-less balance_dirty_pages]
>> As said, I'd really like if Wu or Jan could explain more about the math
>> and IO patterns that went into this tremendous work, and how it should
>> affect us fs maintainers in means of advantages and disadvantages. If
>> digging too deeply into this is not interesting for every body, perhaps
>> a side meeting with fewer people is also possible.
>>
>> [Aligned write-back]
>> I have just finished raid5/6 support in my filesystem and will be sending
>> a patch that tries very aggressively to align IO on stripe boundaries.
>> I did not take the btrfs way of cut/paste of the write_cache_pages()  
>> function
>> to better fit the bill. I used the wbc->nr_to_write to trim down IO on  
>> stripe
>> alignment. Together with some internal structure games, I now have a much
>> better situation then untouched code. Better I mean that if I have simple
>> linear dd IO on a file, I can see o(90%) aligned IOs as opposed to 20%  
>> before
>> that patch. The only remaining issue, I think I have not fully  
>> investigated
>> it yet, is that: because I do not want any residues left from outside the
>> writepages() call so I do not need to sync and lock with flush, and have  
>> a
>> "flushing" flag in my writeout path. So what I still get is that  
>> sometimes
>> the writeback is able to catch up with dd and I get short writes at the
>> reminder, which makes the end of this call and the start of the next call
>> unaligned.
>>
>> I envision a simple BDI members just like ra_pages for readahead that  
>> better
>> govern the writeback chunking. (And is accounted for in the fairness).
>>
>> [Smarter/more cache eviction patterns]
>> I love it when I do a simple dd test in a UML (300Mg of ram) and half  
>> way down
>> I get these fat WARN_ONs of the iscsi tcp writeback failing to allocate  
>> network
>> buffers. And I did lower the writeback ratio a lot because the default  
>> of 20% does
>> not work for a long time, like since 35 or 36. The UML is not the only  
>> affected
>> system any low-memory embedded-like but 64 bit system would be. Now the  
>> IO does
>> complete eventually but the performance is down to 20%.
>>
>> Now for a dd or cp like work pattern I would like the pages be freed  
>> much more
>> aggressively, like right after IO completion because I most certainly  
>> will not
>> use them again. On the other side git for example will write a big  
>> sequential
>> file then immediately turn and read it, so cache presence is a win. But  
>> I think
>> we can still come up with good patterns that take into account the  
>> number of
>> fileh opened on an inode, and some hot inode history to come up with  
>> better
>> patterns. (Some of this history we already have with the security  
>> plugins)
>>
>> And there are other topics that I had, but can remember right now.
>>
>> Thanks
>> Boaz
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"  
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 
> 

Re: [LSF/MM TOPIC] Writeback - current state and future

[Boaz Harrosh]

On 02/06/2011 05:13 PM, Sorin Faibish wrote:
> I was thinking to have a special track for all the writeback related  
> topics.
> I would like also to include a discussion on new cache writeback paterns
> with the target to prevent any cache swaps that are becoming a bigger  
> problem
> when dealing with servers wir 100's GB caches. The swap is the worst that
> could happen to the performance of such systems. I will share my latest  
> findings
> in the cache writeback in continuation to my previous discussion at last  
> LSF.
> 
> /Sorin
> 

Yes, you should try out Wu Fengguang's Latest patches, they fix lots of
what you described in last LSF, and with similar philosophy to what we
talked about. Definitely interesting to see results.

Thanks
Boaz

> On Sun, 06 Feb 2011 05:43:20 -0500, Boaz Harrosh <bharrosh@panasas.com>  
> wrote:
> 
>> On 02/04/2011 06:42 PM, Jan Kara wrote:
>>>   Hi,
>>>
>>>   I'd like to have one session about writeback. The content would highly
>>> depend on the current state of things but on a general level, I'd like  
>>> to
>>> quickly sum up what went into the kernel (or is mostly ready to go)  
>>> since
>>> last LSF (handling of background writeback, livelock avoidance), what is
>>> being worked on - IO-less balance_dirty_pages() (if it won't be in the
>>> mostly done section), what other things need to be improved (kswapd
>>> writeout, writeback_inodes_sb_if_idle() mess, come to my mind now)
>>>
>>> 								Honza
>>
>> Ha, I most certainly want to participate in this talk. I wanted to
>> suggest it myself.
>>
>> Topics that I would like to raise on the matter.
>>
>> [IO-less balance_dirty_pages]
>> As said, I'd really like if Wu or Jan could explain more about the math
>> and IO patterns that went into this tremendous work, and how it should
>> affect us fs maintainers in means of advantages and disadvantages. If
>> digging too deeply into this is not interesting for every body, perhaps
>> a side meeting with fewer people is also possible.
>>
>> [Aligned write-back]
>> I have just finished raid5/6 support in my filesystem and will be sending
>> a patch that tries very aggressively to align IO on stripe boundaries.
>> I did not take the btrfs way of cut/paste of the write_cache_pages()  
>> function
>> to better fit the bill. I used the wbc->nr_to_write to trim down IO on  
>> stripe
>> alignment. Together with some internal structure games, I now have a much
>> better situation then untouched code. Better I mean that if I have simple
>> linear dd IO on a file, I can see o(90%) aligned IOs as opposed to 20%  
>> before
>> that patch. The only remaining issue, I think I have not fully  
>> investigated
>> it yet, is that: because I do not want any residues left from outside the
>> writepages() call so I do not need to sync and lock with flush, and have  
>> a
>> "flushing" flag in my writeout path. So what I still get is that  
>> sometimes
>> the writeback is able to catch up with dd and I get short writes at the
>> reminder, which makes the end of this call and the start of the next call
>> unaligned.
>>
>> I envision a simple BDI members just like ra_pages for readahead that  
>> better
>> govern the writeback chunking. (And is accounted for in the fairness).
>>
>> [Smarter/more cache eviction patterns]
>> I love it when I do a simple dd test in a UML (300Mg of ram) and half  
>> way down
>> I get these fat WARN_ONs of the iscsi tcp writeback failing to allocate  
>> network
>> buffers. And I did lower the writeback ratio a lot because the default  
>> of 20% does
>> not work for a long time, like since 35 or 36. The UML is not the only  
>> affected
>> system any low-memory embedded-like but 64 bit system would be. Now the  
>> IO does
>> complete eventually but the performance is down to 20%.
>>
>> Now for a dd or cp like work pattern I would like the pages be freed  
>> much more
>> aggressively, like right after IO completion because I most certainly  
>> will not
>> use them again. On the other side git for example will write a big  
>> sequential
>> file then immediately turn and read it, so cache presence is a win. But  
>> I think
>> we can still come up with good patterns that take into account the  
>> number of
>> fileh opened on an inode, and some hot inode history to come up with  
>> better
>> patterns. (Some of this history we already have with the security  
>> plugins)
>>
>> And there are other topics that I had, but can remember right now.
>>
>> Thanks
>> Boaz
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"  
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 
> 

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] Writeback - current state and future

[Jan Kara]

On Sun 06-02-11 10:13:41, Sorin Faibish wrote:
> I was thinking to have a special track for all the writeback related
> topics.
  Well, a separate track might be a bit too much I feel ;). I'm interested
also in other things that are happening... We'll see what the program will
be but I can imagine we can discuss for a couple of hours but that might be
just a discussion in a small circle over a <enter preferable drink>.

> I would like also to include a discussion on new cache writeback paterns
> with the target to prevent any cache swaps that are becoming a
> bigger problem
> when dealing with servers wir 100's GB caches. The swap is the worst that
> could happen to the performance of such systems. I will share my
> latest findings
> in the cache writeback in continuation to my previous discussion at
> last LSF.
  I'm not sure what do you exactly mean by 'cache swaps'. If you mean that
your application private cache is swapped out, then I can imagine this is a
problem but I'd need more details to tell how big.

									Honza 
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: [LSF/MM TOPIC] Writeback - current state and future

[Jan Kara]

On Sun 06-02-11 10:13:41, Sorin Faibish wrote:
> I was thinking to have a special track for all the writeback related
> topics.
  Well, a separate track might be a bit too much I feel ;). I'm interested
also in other things that are happening... We'll see what the program will
be but I can imagine we can discuss for a couple of hours but that might be
just a discussion in a small circle over a <enter preferable drink>.

> I would like also to include a discussion on new cache writeback paterns
> with the target to prevent any cache swaps that are becoming a
> bigger problem
> when dealing with servers wir 100's GB caches. The swap is the worst that
> could happen to the performance of such systems. I will share my
> latest findings
> in the cache writeback in continuation to my previous discussion at
> last LSF.
  I'm not sure what do you exactly mean by 'cache swaps'. If you mean that
your application private cache is swapped out, then I can imagine this is a
problem but I'd need more details to tell how big.

									Honza 
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] Writeback - current state and future

[sfaibish]

On Fri, 11 Feb 2011 09:47:17 -0500, Jan Kara <jack@suse.cz> wrote:

> On Sun 06-02-11 10:13:41, Sorin Faibish wrote:
>> I was thinking to have a special track for all the writeback related
>> topics.
>   Well, a separate track might be a bit too much I feel ;). I'm  
> interested
> also in other things that are happening... We'll see what the program  
> will
> be but I can imagine we can discuss for a couple of hours but that might  
> be
> just a discussion in a small circle over a <enter preferable drink>.
No problem. I pay for the beer. :) You make the expert pick.

>
>> I would like also to include a discussion on new cache writeback paterns
>> with the target to prevent any cache swaps that are becoming a
>> bigger problem
>> when dealing with servers wir 100's GB caches. The swap is the worst  
>> that
>> could happen to the performance of such systems. I will share my
>> latest findings
>> in the cache writeback in continuation to my previous discussion at
>> last LSF.
>   I'm not sure what do you exactly mean by 'cache swaps'. If you mean  
> that
> your application private cache is swapped out, then I can imagine this  
> is a
> problem but I'd need more details to tell how big.
What I meant is to prevent any global cache swap. Think that you have to  
SWAP
256GB of cache to a 120MB/sec SATA disk. How long it will take? Cannot be
tolerated. Even if you use SSD at say 1GB/sec it is still a long time. Not
typical but common in HPC. I am not sure you saw my latest results but I
had an example where the swap was taking a long time to the point that a
build on a small memory system didn't finish. The good news are that the
latest kernels 37 RC3 made progress. I have additional data to present.
I will present the latest results next week at FAST conference.

/Sorin

>
> 									Honza



-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division
         EMC²
where information lives

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : sfaibish@emc.com

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] Writeback - current state and future

[sfaibish]

On Fri, 11 Feb 2011 09:47:17 -0500, Jan Kara <jack@suse.cz> wrote:

> On Sun 06-02-11 10:13:41, Sorin Faibish wrote:
>> I was thinking to have a special track for all the writeback related
>> topics.
>   Well, a separate track might be a bit too much I feel ;). I'm  
> interested
> also in other things that are happening... We'll see what the program  
> will
> be but I can imagine we can discuss for a couple of hours but that might  
> be
> just a discussion in a small circle over a <enter preferable drink>.
No problem. I pay for the beer. :) You make the expert pick.

>
>> I would like also to include a discussion on new cache writeback paterns
>> with the target to prevent any cache swaps that are becoming a
>> bigger problem
>> when dealing with servers wir 100's GB caches. The swap is the worst  
>> that
>> could happen to the performance of such systems. I will share my
>> latest findings
>> in the cache writeback in continuation to my previous discussion at
>> last LSF.
>   I'm not sure what do you exactly mean by 'cache swaps'. If you mean  
> that
> your application private cache is swapped out, then I can imagine this  
> is a
> problem but I'd need more details to tell how big.
What I meant is to prevent any global cache swap. Think that you have to  
SWAP
256GB of cache to a 120MB/sec SATA disk. How long it will take? Cannot be
tolerated. Even if you use SSD at say 1GB/sec it is still a long time. Not
typical but common in HPC. I am not sure you saw my latest results but I
had an example where the swap was taking a long time to the point that a
build on a small memory system didn't finish. The good news are that the
latest kernels 37 RC3 made progress. I have additional data to present.
I will present the latest results next week at FAST conference.

/Sorin

>
> 									Honza



-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division
         EMC2
where information lives

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : sfaibish@emc.com

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] Writeback - current state and future

[Sorin Faibish]

Jan,

It looks like people in LSF are not so interested in writeback problems
and we will not have a discussion on this. Too bad as I have new results
to present regarding the latest patches in the kernel related to writeback
and I am not sure for the best.

/Sorin


On Fri, 11 Feb 2011 11:22:18 -0500, sfaibish <sfaibish@emc.com> wrote:

> On Fri, 11 Feb 2011 09:47:17 -0500, Jan Kara <jack@suse.cz> wrote:
>
>> On Sun 06-02-11 10:13:41, Sorin Faibish wrote:
>>> I was thinking to have a special track for all the writeback related
>>> topics.
>>   Well, a separate track might be a bit too much I feel ;). I'm  
>> interested
>> also in other things that are happening... We'll see what the program  
>> will
>> be but I can imagine we can discuss for a couple of hours but that  
>> might be
>> just a discussion in a small circle over a <enter preferable drink>.
> No problem. I pay for the beer. :) You make the expert pick.
>
>>
>>> I would like also to include a discussion on new cache writeback  
>>> paterns
>>> with the target to prevent any cache swaps that are becoming a
>>> bigger problem
>>> when dealing with servers wir 100's GB caches. The swap is the worst  
>>> that
>>> could happen to the performance of such systems. I will share my
>>> latest findings
>>> in the cache writeback in continuation to my previous discussion at
>>> last LSF.
>>   I'm not sure what do you exactly mean by 'cache swaps'. If you mean  
>> that
>> your application private cache is swapped out, then I can imagine this  
>> is a
>> problem but I'd need more details to tell how big.
> What I meant is to prevent any global cache swap. Think that you have to  
> SWAP
> 256GB of cache to a 120MB/sec SATA disk. How long it will take? Cannot be
> tolerated. Even if you use SSD at say 1GB/sec it is still a long time.  
> Not
> typical but common in HPC. I am not sure you saw my latest results but I
> had an example where the swap was taking a long time to the point that a
> build on a small memory system didn't finish. The good news are that the
> latest kernels 37 RC3 made progress. I have additional data to present.
> I will present the latest results next week at FAST conference.
>
> /Sorin
>
>>
>> 									Honza
>
>
>



-- 
Best Regards
Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division

        EMC²
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : sfaibish@emc.com

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] Writeback - current state and future

[Sorin Faibish]

Jan,

It looks like people in LSF are not so interested in writeback problems
and we will not have a discussion on this. Too bad as I have new results
to present regarding the latest patches in the kernel related to writeback
and I am not sure for the best.

/Sorin


On Fri, 11 Feb 2011 11:22:18 -0500, sfaibish <sfaibish@emc.com> wrote:

> On Fri, 11 Feb 2011 09:47:17 -0500, Jan Kara <jack@suse.cz> wrote:
>
>> On Sun 06-02-11 10:13:41, Sorin Faibish wrote:
>>> I was thinking to have a special track for all the writeback related
>>> topics.
>>   Well, a separate track might be a bit too much I feel ;). I'm  
>> interested
>> also in other things that are happening... We'll see what the program  
>> will
>> be but I can imagine we can discuss for a couple of hours but that  
>> might be
>> just a discussion in a small circle over a <enter preferable drink>.
> No problem. I pay for the beer. :) You make the expert pick.
>
>>
>>> I would like also to include a discussion on new cache writeback  
>>> paterns
>>> with the target to prevent any cache swaps that are becoming a
>>> bigger problem
>>> when dealing with servers wir 100's GB caches. The swap is the worst  
>>> that
>>> could happen to the performance of such systems. I will share my
>>> latest findings
>>> in the cache writeback in continuation to my previous discussion at
>>> last LSF.
>>   I'm not sure what do you exactly mean by 'cache swaps'. If you mean  
>> that
>> your application private cache is swapped out, then I can imagine this  
>> is a
>> problem but I'd need more details to tell how big.
> What I meant is to prevent any global cache swap. Think that you have to  
> SWAP
> 256GB of cache to a 120MB/sec SATA disk. How long it will take? Cannot be
> tolerated. Even if you use SSD at say 1GB/sec it is still a long time.  
> Not
> typical but common in HPC. I am not sure you saw my latest results but I
> had an example where the swap was taking a long time to the point that a
> build on a small memory system didn't finish. The good news are that the
> latest kernels 37 RC3 made progress. I have additional data to present.
> I will present the latest results next week at FAST conference.
>
> /Sorin
>
>>
>> 									Honza
>
>
>



-- 
Best Regards
Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division

        EMC2
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : sfaibish@emc.com

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [Lsf-pc] [LSF/MM TOPIC] Writeback - current state and future

[James Bottomley]

On Sat, 2011-02-26 at 16:03 -0500, Sorin Faibish wrote:
> It looks like people in LSF are not so interested in writeback problems
> and we will not have a discussion on this. Too bad as I have new results
> to present regarding the latest patches in the kernel related to writeback
> and I am not sure for the best.

I'm not entirely sure how you arrive at this conclusion.  The programme
isn't decided yet, but I'd be pretty certain there'll be another plenary
session on writeback given the interest.

James

Re: [Lsf-pc] [LSF/MM TOPIC] Writeback - current state and future

[James Bottomley]

On Sat, 2011-02-26 at 16:03 -0500, Sorin Faibish wrote:
> It looks like people in LSF are not so interested in writeback problems
> and we will not have a discussion on this. Too bad as I have new results
> to present regarding the latest patches in the kernel related to writeback
> and I am not sure for the best.

I'm not entirely sure how you arrive at this conclusion.  The programme
isn't decided yet, but I'd be pretty certain there'll be another plenary
session on writeback given the interest.

James


--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [Lsf-pc] [LSF/MM TOPIC] Writeback - current state and future

[Sorin Faibish]

On Sat, 26 Feb 2011 16:07:20 -0500, James Bottomley  
<James.Bottomley@hansenpartnership.com> wrote:

> On Sat, 2011-02-26 at 16:03 -0500, Sorin Faibish wrote:
>> It looks like people in LSF are not so interested in writeback problems
>> and we will not have a discussion on this. Too bad as I have new results
>> to present regarding the latest patches in the kernel related to  
>> writeback
>> and I am not sure for the best.
>
> I'm not entirely sure how you arrive at this conclusion.  The programme
> isn't decided yet, but I'd be pretty certain there'll be another plenary
> session on writeback given the interest.
Well I was told otherwise (and Boaz) and I didn't see I was invited to the
LSF. Jan made a request and I just assumed that piggy back on his request  
will
be enough. If you think I am wrong I will be more than happy to retract my
complain and attend to present my newest test results with the latest  
patches.

/Sorin

>
> James
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"  
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Best Regards
Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division

        EMC²
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : sfaibish@emc.com

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [Lsf-pc] [LSF/MM TOPIC] Writeback - current state and future

[Sorin Faibish]

On Sat, 26 Feb 2011 16:07:20 -0500, James Bottomley  
<James.Bottomley@hansenpartnership.com> wrote:

> On Sat, 2011-02-26 at 16:03 -0500, Sorin Faibish wrote:
>> It looks like people in LSF are not so interested in writeback problems
>> and we will not have a discussion on this. Too bad as I have new results
>> to present regarding the latest patches in the kernel related to  
>> writeback
>> and I am not sure for the best.
>
> I'm not entirely sure how you arrive at this conclusion.  The programme
> isn't decided yet, but I'd be pretty certain there'll be another plenary
> session on writeback given the interest.
Well I was told otherwise (and Boaz) and I didn't see I was invited to the
LSF. Jan made a request and I just assumed that piggy back on his request  
will
be enough. If you think I am wrong I will be more than happy to retract my
complain and attend to present my newest test results with the latest  
patches.

/Sorin

>
> James
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"  
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Best Regards
Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division

        EMC2
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : sfaibish@emc.com

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [Lsf-pc] [LSF/MM TOPIC] Writeback - current state and future

[James Bottomley]

On Sat, 2011-02-26 at 18:21 -0500, Sorin Faibish wrote:
> On Sat, 26 Feb 2011 16:07:20 -0500, James Bottomley  
> <James.Bottomley@hansenpartnership.com> wrote:
> 
> > On Sat, 2011-02-26 at 16:03 -0500, Sorin Faibish wrote:
> >> It looks like people in LSF are not so interested in writeback problems
> >> and we will not have a discussion on this. Too bad as I have new results
> >> to present regarding the latest patches in the kernel related to  
> >> writeback
> >> and I am not sure for the best.
> >
> > I'm not entirely sure how you arrive at this conclusion.  The programme
> > isn't decided yet, but I'd be pretty certain there'll be another plenary
> > session on writeback given the interest.
> Well I was told otherwise (and Boaz)

OK. so let me state categorically that the Programme Committee hasn't
made any decisions regarding topics yet and, as I said, I'm pretty
certain writeback will be another plenary session like it was last year.

>  and I didn't see I was invited to the LSF. Jan made a request and I
> just assumed that piggy back on his request will be enough.

I'm not entirely sure I parse this sentence correctly.  However, the
reason you didn't get an invite is because you didn't request one.  The
CFP 

http://marc.info/?l=linux-fsdevel&m=129503688923313

Was pretty clear ... to get an invite you need to send a topic or attend
email to the PC list, which you didn't do.  Even if I look at the three
replies you made to other people's topic or attend emails, I'd be very
hard pressed to construe any of them as a request to attend.

>  If you think I am wrong I will be more than happy to retract my
> complain and attend to present my newest test results with the latest  
> patches.

I'm afraid that we're pretty much oversubscribed on all tracks at LSF/MM
2011 now (in fact, the FS track is very oversubscribed).  I can put you
on the reserve list in case there are any cancellations, if you like.

Just for future reference: LSF definitely isn't a venue to turn up to
present patches.  The correct way to do that is to the relevant mailing
list for proper discussion and consideration.  LSF can be used to
discuss existing patches, and even to try to reach consensus on a set of
patches on the mailing lists, but turning up with unreviewed patches
just wastes everyone's time.

James

Re: [Lsf-pc] [LSF/MM TOPIC] Writeback - current state and future

[James Bottomley]

On Sat, 2011-02-26 at 18:21 -0500, Sorin Faibish wrote:
> On Sat, 26 Feb 2011 16:07:20 -0500, James Bottomley  
> <James.Bottomley@hansenpartnership.com> wrote:
> 
> > On Sat, 2011-02-26 at 16:03 -0500, Sorin Faibish wrote:
> >> It looks like people in LSF are not so interested in writeback problems
> >> and we will not have a discussion on this. Too bad as I have new results
> >> to present regarding the latest patches in the kernel related to  
> >> writeback
> >> and I am not sure for the best.
> >
> > I'm not entirely sure how you arrive at this conclusion.  The programme
> > isn't decided yet, but I'd be pretty certain there'll be another plenary
> > session on writeback given the interest.
> Well I was told otherwise (and Boaz)

OK. so let me state categorically that the Programme Committee hasn't
made any decisions regarding topics yet and, as I said, I'm pretty
certain writeback will be another plenary session like it was last year.

>  and I didn't see I was invited to the LSF. Jan made a request and I
> just assumed that piggy back on his request will be enough.

I'm not entirely sure I parse this sentence correctly.  However, the
reason you didn't get an invite is because you didn't request one.  The
CFP 

http://marc.info/?l=linux-fsdevel&m=129503688923313

Was pretty clear ... to get an invite you need to send a topic or attend
email to the PC list, which you didn't do.  Even if I look at the three
replies you made to other people's topic or attend emails, I'd be very
hard pressed to construe any of them as a request to attend.

>  If you think I am wrong I will be more than happy to retract my
> complain and attend to present my newest test results with the latest  
> patches.

I'm afraid that we're pretty much oversubscribed on all tracks at LSF/MM
2011 now (in fact, the FS track is very oversubscribed).  I can put you
on the reserve list in case there are any cancellations, if you like.

Just for future reference: LSF definitely isn't a venue to turn up to
present patches.  The correct way to do that is to the relevant mailing
list for proper discussion and consideration.  LSF can be used to
discuss existing patches, and even to try to reach consensus on a set of
patches on the mailing lists, but turning up with unreviewed patches
just wastes everyone's time.

James


--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [Lsf-pc] [LSF/MM TOPIC] Writeback - current state and future

[Trond Myklebust]

On Sat, 2011-02-26 at 18:48 -0500, James Bottomley wrote: 
> On Sat, 2011-02-26 at 18:21 -0500, Sorin Faibish wrote:
> I'm not entirely sure I parse this sentence correctly.  However, the
> reason you didn't get an invite is because you didn't request one.  The
> CFP 
> 
> http://marc.info/?l=linux-fsdevel&m=129503688923313
> 
> Was pretty clear ... to get an invite you need to send a topic or attend
> email to the PC list, which you didn't do.  Even if I look at the three
> replies you made to other people's topic or attend emails, I'd be very
> hard pressed to construe any of them as a request to attend.
> 
> >  If you think I am wrong I will be more than happy to retract my
> > complain and attend to present my newest test results with the latest  
> > patches.
> 
> I'm afraid that we're pretty much oversubscribed on all tracks at LSF/MM
> 2011 now (in fact, the FS track is very oversubscribed).  I can put you
> on the reserve list in case there are any cancellations, if you like.

I agree. If there are cancellations, then there may be a second round of
invitations to those who are wait-listed, but until then, we won't be
making any exceptions to the rules outlined in the CFP.

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: [Lsf-pc] [LSF/MM TOPIC] Writeback - current state and future

[Trond Myklebust]

On Sat, 2011-02-26 at 18:48 -0500, James Bottomley wrote: 
> On Sat, 2011-02-26 at 18:21 -0500, Sorin Faibish wrote:
> I'm not entirely sure I parse this sentence correctly.  However, the
> reason you didn't get an invite is because you didn't request one.  The
> CFP 
> 
> http://marc.info/?l=linux-fsdevel&m=129503688923313
> 
> Was pretty clear ... to get an invite you need to send a topic or attend
> email to the PC list, which you didn't do.  Even if I look at the three
> replies you made to other people's topic or attend emails, I'd be very
> hard pressed to construe any of them as a request to attend.
> 
> >  If you think I am wrong I will be more than happy to retract my
> > complain and attend to present my newest test results with the latest  
> > patches.
> 
> I'm afraid that we're pretty much oversubscribed on all tracks at LSF/MM
> 2011 now (in fact, the FS track is very oversubscribed).  I can put you
> on the reserve list in case there are any cancellations, if you like.

I agree. If there are cancellations, then there may be a second round of
invitations to those who are wait-listed, but until then, we won't be
making any exceptions to the rules outlined in the CFP.

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>