reiser4 and laptop_mode

reiser4 and laptop_mode

[Sinitsyn Valentine]

Hi all,

I'm considering installing Reiser4 on my laptop, but I also want to
use laptop_mode (http://www.xs4all.nl/~bsamwel/laptop_mode/index.html)
to save battery power. So I'm wondering wether these two products are
compatible with each other? I know that Reiser3 and ext3 did require
special patches (now included in mainstream kernels) which schedule
commits in a way which allows hard drive to spin down. I've looked
through Google and this mailing list but didn't find any references to
similar patches for Reiser4. Are they needed but nobody wrote them yet
or is Reiser4 spindown-friendly just out of the box? The main point of
spindown-friendliness is an ability to tune a period between two
commits (like "commit=N" mount option in Reiser3, AFAIU), but the only
suitable parameter I found glancing through Reiser4 sources is
"atom_max_age".

Thanks in advance.

Best regards,
Valentine Sinitsyn.

Re: reiser4 and laptop_mode

[David Masover]

Sinitsyn Valentine wrote:
> Hi all,
> 
> I'm considering installing Reiser4 on my laptop, but I also want to
> use laptop_mode (http://www.xs4all.nl/~bsamwel/laptop_mode/index.html)
> to save battery power. So I'm wondering wether these two products are
> compatible with each other? I know that Reiser3 and ext3 did require
> special patches (now included in mainstream kernels) which schedule
> commits in a way which allows hard drive to spin down. I've looked
> through Google and this mailing list but didn't find any references to
> similar patches for Reiser4. Are they needed but nobody wrote them yet
> or is Reiser4 spindown-friendly just out of the box?

Reiser4 is spindown-friendly in one way -- until you run out of RAM, it
won't commit.  In fact, if you have enough RAM, you won't ever touch the
disk -- deleting a file before it's committed means it never touches disk.

It is not as spindown-friendly as laptop_mode, which notices when the
drive has to spin up anyway (maybe through a read) and flushes all
writes.  Don't know if they are compatible.

Re: reiser4 and laptop_mode

[Hans Reiser]

David Masover wrote:

>Sinitsyn Valentine wrote:
>  
>
>>Hi all,
>>
>>I'm considering installing Reiser4 on my laptop, but I also want to
>>use laptop_mode (http://www.xs4all.nl/~bsamwel/laptop_mode/index.html)
>>to save battery power. So I'm wondering wether these two products are
>>compatible with each other? I know that Reiser3 and ext3 did require
>>special patches (now included in mainstream kernels) which schedule
>>commits in a way which allows hard drive to spin down. I've looked
>>through Google and this mailing list but didn't find any references to
>>similar patches for Reiser4. Are they needed but nobody wrote them yet
>>or is Reiser4 spindown-friendly just out of the box?
>>    
>>
>
>Reiser4 is spindown-friendly in one way -- until you run out of RAM, it
>won't commit. 
>
This is not true (it would need to be fixed if it was).  You can adjust
how frequent commits are if you don't like our kernel compilation
optimized defaults.

> In fact, if you have enough RAM, you won't ever touch the
>disk -- deleting a file before it's committed means it never touches disk.
>
>It is not as spindown-friendly as laptop_mode, which notices when the
>drive has to spin up anyway (maybe through a read) and flushes all
>writes.  Don't know if they are compatible.
>  
>
We should work to integrate well with it.  Zam, can you look at that? 
Thanks.

>
>  
>

Re: reiser4 and laptop_mode

[Gregory Maxwell]

On 10/17/05, Hans Reiser <reiser@namesys.com> wrote:
> > In fact, if you have enough RAM, you won't ever touch the
> >disk -- deleting a file before it's committed means it never touches disk.
> >
> >It is not as spindown-friendly as laptop_mode, which notices when the
> >drive has to spin up anyway (maybe through a read) and flushes all
> >writes.  Don't know if they are compatible.
> >
> >
> We should work to integrate well with it.  Zam, can you look at that?
> Thanks.

Actually, laptop mode flushes when there is a write and sync all
pending transactions just before spindown. (delaying the write as long
as possible to hopefully get as much in one pass as possible).

In the future when enough API is exposed to make a nice interface for
multi-syscall transactions with partial sync (i.e. only forced syncs
of blocks related to transactions which demand physical fixation), it
would be nice if the commit logic were smart enough to grab other
nearby small transactions and batch them into the same commit.

Re: reiser4 and laptop_mode

[Alexander Zarochentsev]

On Tuesday 18 October 2005 06:34, Gregory Maxwell wrote:
> On 10/17/05, Hans Reiser <reiser@namesys.com> wrote:
> > > In fact, if you have enough RAM, you won't ever touch the
> > >disk -- deleting a file before it's committed means it never touches
> > > disk.
> > >
> > >It is not as spindown-friendly as laptop_mode, which notices when the
> > >drive has to spin up anyway (maybe through a read) and flushes all
> > >writes.  Don't know if they are compatible.
> >
> > We should work to integrate well with it.  Zam, can you look at that?
> > Thanks.
>
> Actually, laptop mode flushes when there is a write and sync all
> pending transactions just before spindown. (delaying the write as long
> as possible to hopefully get as much in one pass as possible).

Does the kernel really know when the disk spins down? 

> In the future when enough API is exposed to make a nice interface for
> multi-syscall transactions with partial sync (i.e. only forced syncs
> of blocks related to transactions which demand physical fixation), it
> would be nice if the commit logic were smart enough to grab other
> nearby small transactions and batch them into the same commit.

If there is a fs-specific 'prepare-to-disk-spindown' hook we can scan the atom 
list and commit all atoms which may cause the disk to be woken up too early.

-- 
Alex.

Re: reiser4 and laptop_mode

[Alexander Zarochentsev]

On Tuesday 18 October 2005 06:34, Gregory Maxwell wrote:
> On 10/17/05, Hans Reiser <reiser@namesys.com> wrote:
> > > In fact, if you have enough RAM, you won't ever touch the
> > >disk -- deleting a file before it's committed means it never touches
> > > disk.
> > >
> > >It is not as spindown-friendly as laptop_mode, which notices when the
> > >drive has to spin up anyway (maybe through a read) and flushes all
> > >writes.  Don't know if they are compatible.
> >
> > We should work to integrate well with it.  Zam, can you look at that?
> > Thanks.
>
> Actually, laptop mode flushes when there is a write and sync all
> pending transactions just before spindown. (delaying the write as long
> as possible to hopefully get as much in one pass as possible).

Does the kernel really know when the disk spins down? 

> In the future when enough API is exposed to make a nice interface for
> multi-syscall transactions with partial sync (i.e. only forced syncs
> of blocks related to transactions which demand physical fixation), it
> would be nice if the commit logic were smart enough to grab other
> nearby small transactions and batch them into the same commit.

If there is a fs-specific 'prepare-to-disk-spindown' hook we can scan the atom 
list and commit all atoms which may cause the disk to be woken up too early.

-- 
Alex.

Re[2]: reiser4 and laptop_mode

[Valentine Sinitsyn]

Hi all,

Wednesday, October 19, 2005, 2:33:47 PM, you wrote:

AZ> On Tuesday 18 October 2005 06:34, Gregory Maxwell wrote:
>> On 10/17/05, Hans Reiser <reiser@namesys.com> wrote:
>> > > In fact, if you have enough RAM, you won't ever touch the
>> > >disk -- deleting a file before it's committed means it never touches
>> > > disk.
>> > >
>> > >It is not as spindown-friendly as laptop_mode, which notices when the
>> > >drive has to spin up anyway (maybe through a read) and flushes all
>> > >writes.  Don't know if they are compatible.
>> >
>> > We should work to integrate well with it.  Zam, can you look at that?
>> > Thanks.
>>
>> Actually, laptop mode flushes when there is a write and sync all
>> pending transactions just before spindown. (delaying the write as long
>> as possible to hopefully get as much in one pass as possible).

AZ> Does the kernel really know when the disk spins down? 
I don't think so. As far as I understand from linux-2.6.10 sources and
docs, laptop_mode works in a following way: it gently "removes"
all pdflush() calls in memory-management code and creates a timer with
pdflush(sys_sync(),0) as callback function. Then, every operation which can cause
spin-up (maybe even reading, but I don't know for sure) advance this
timer for laptop_mode*HZ amount of seconds thus guaranteeing that no
writing of dirty-pages will occur during this period and hard disk
will have time to spin-down. So, to conclude, kernel does not know
when disk spins down but it know the functions which may cause him to
spin-up.

>> In the future when enough API is exposed to make a nice interface for
>> multi-syscall transactions with partial sync (i.e. only forced syncs
>> of blocks related to transactions which demand physical fixation), it
>> would be nice if the commit logic were smart enough to grab other
>> nearby small transactions and batch them into the same commit.

AZ> If there is a fs-specific 'prepare-to-disk-spindown' hook we can scan the atom
AZ> list and commit all atoms which may cause the disk to be woken up too early.
Don't know anything about hooks. As I've said earlier, the only
filesystem which deals with laptop_mode explicitly is XFS and the
reason (in my opinion) is because it has it's own syncing daemon
separate from mm-code and the rest.

I'm not quite familiar with kernel internals but I suspect that if
Reiser4 use standard kernel facilities to commit atoms (and these
writeback functions are aware of laptop_mode), it should be compatible
in sense I've asked for.

Best regards,
Valentine

Re[2]: reiser4 and laptop_mode

[Valentine Sinitsyn]

Hello,

please ignore my previous post. It was wrong (not in a whole, but...).

AZ> On Tuesday 18 October 2005 06:34, Gregory Maxwell wrote:
>> On 10/17/05, Hans Reiser <reiser@namesys.com> wrote:
>> > > In fact, if you have enough RAM, you won't ever touch the
>> > >disk -- deleting a file before it's committed means it never touches
>> > > disk.
>> > >
>> > >It is not as spindown-friendly as laptop_mode, which notices when the
>> > >drive has to spin up anyway (maybe through a read) and flushes all
>> > >writes.  Don't know if they are compatible.
>> >
>> > We should work to integrate well with it.  Zam, can you look at that?
>> > Thanks.
>>
>> Actually, laptop mode flushes when there is a write and sync all
>> pending transactions just before spindown. (delaying the write as long
>> as possible to hopefully get as much in one pass as possible).

AZ> Does the kernel really know when the disk spins down?
No, kernel doesn't know when the disk is going to spin down. But it
certainly knows operations which will cause drive to spin up. And, at the
very end of such operations laptop_mode schedules writeback of all
filesystem data. This is done via laptop_io_completion() call in
end_that_request_last() function from drivers/block/ll_rw_blk.c.
By default, this occurs two seconds after the above-mentioned operation and
is controlled by /proc/sys/vm/laptop_mode value and laptop_mode_wbr_timer
timer defined in mm/page-writeback.c. This timer wakes up pdflush() and
cause it to do_sync(0) as defined in fs/buffer.c. laptop_mode uses
some logic to prolong timer if hard disk is still in use and stop it
if syncing occurs before the specified period. One can certainly expect
that HD would not spun down during two seconds after the IDE operation so
filesystem writeback will not cause another spinup.

>> In the future when enough API is exposed to make a nice interface for
>> multi-syscall transactions with partial sync (i.e. only forced syncs
>> of blocks related to transactions which demand physical fixation), it
>> would be nice if the commit logic were smart enough to grab other
>> nearby small transactions and batch them into the same commit.

AZ> If there is a fs-specific 'prepare-to-disk-spindown' hook we can scan the atom
AZ> list and commit all atoms which may cause the disk to be woken up too early.
As far as I understand, no. According to the scheme described above,
it seems that you are compatible with laptop_mode if you are just
marking your objects dirty and let
pdflush/page-writeback.c/fs-writeback.c do their work to sync it with
disk. If you are using alternative syncing scheme (like XFS which has
it's own sync daemon), you need some patches.
Anyway, this is just my assumptions so I'll be grateful if someone
from kernel hackers can prove it or point out what's wrong with it.
Also it will be interesting to know if  Reiser4 is compatible with
laptop_mode from this point of view (if it is true, of course). Many
thanks in advance.

Best regards,
Valentine

Re[2]: reiser4 and laptop_mode

[Valentine Sinitsyn]

Hi, all,

HR> We should work to integrate well with it.  Zam, can you look at that?
HR> Thanks.
I was looking through linux-2.6.10 sources this morning and did not found
laptop_mode anywhere in filesystem-specific code (except xfs). I'm not
a kernel hacker but it seems to me that laptop_mode is compatible with
everything which have customizable committing period. laptop_mode
tools (shell scripts which are used to activate this feature) do
mainly two things: they set up commit period in
/proc/sys/vm/laptop_mode (this data is used later in pdflush
controlling code etc), remount filesystems with -o
commit=laptop_mode_value and set read-ahead value for hd[a-z].

Am I right?

P.S. Thanks for the replies.

Best regards,
Valentine

Re: reiser4 and laptop_mode

[Hans Reiser]

Valentine Sinitsyn wrote:

>Hi, all,
>
>HR> We should work to integrate well with it.  Zam, can you look at that?
>HR> Thanks.
>I was looking through linux-2.6.10 sources this morning and did not found
>laptop_mode anywhere in filesystem-specific code (except xfs). I'm not
>a kernel hacker but it seems to me that laptop_mode is compatible with
>everything which have customizable committing period. laptop_mode
>tools (shell scripts which are used to activate this feature) do
>mainly two things: they set up commit period in
>/proc/sys/vm/laptop_mode (this data is used later in pdflush
>controlling code etc), remount filesystems with -o
>commit=laptop_mode_value and set read-ahead value for hd[a-z].
>
>Am I right?
>
>P.S. Thanks for the replies.
>
>Best regards,
>Valentine
>
>
>
>  
>
zam, please respond.  Are you at work today?