udpated data logging available

udpated data logging available

[Chris Mason]

Hello all,

This doesn't have the data=ordered performance fixes because I got
distracted fixing io latency problems in 2.4.21.  Those were screwing up
my benchmarks, so I couldn't really tell if things were faster or not
;-)  Anyway, I'm back on track now, and since 2.4.21 is out I've just
copied Oleg's merge into my data logging directory.  I'll add the
experimental performance patches later today.

But, the code in my data logging directory now is what I would like to
see merged into 2.4.22-pre asap (pending namesys approval), so review
and testing would be appreciated.

ftp.suse.com/pub/people/mason/patches/data-logging/2.4.21

It might take a 30 minutes or so for the rsync to complete.  

-chris

Re: udpated data logging available

[Chris Mason]

Hello again,

ftp.suse.com/pub/people/mason/patches/data-logging/2.4.21/experimental

Has two additional patches.  The first is io-stalls-logging-6.diff,
which is very similar to the io stalling code I've been posting on the
linux kernel list.  It's unrelated to reiserfs really, and fixes some
fairness issues at the block device layer.

The second is reiserfs-jh-1, which changes where the lists live for
data=ordered and tail buffers.  It allows us to do a few things:

fdatasync without triggering a commit for tails or data=ordered buffers.
O_DIRECT and data=ordered.
O_DIRECT without special code to make sure tails get flushed.
optimizations on data=ordered write back.

The two O_DIRECT parts aren't coded yet, but I wanted to get this patch
out there for people to try.  The good news is the O_DIRECT stuff
involves removing code instead of adding it, so it is just a matter of
testing.

The reiserfs-jh code is also needed for a worthwhile port to 2.5, it
should make things easier overall from here on.  Handle with care, it's
been through an overnight run, but I make no promises the jh code won't
give you a chance to see how good your backups are.

io-stalling-6 is considered stable, it is just in the experimental
directory because it is not strictly needed for the data logging in
general.

-chris

Re: udpated data logging available

[Chris Mason]

On Wed, 2003-06-18 at 09:56, Chris Mason wrote:
> Hello again,
> 
> ftp.suse.com/pub/people/mason/patches/data-logging/2.4.21/experimental
> 
> Has two additional patches.  The first is io-stalls-logging-6.diff,
> which is very similar to the io stalling code I've been posting on the
> linux kernel list.  It's unrelated to reiserfs really, and fixes some
> fairness issues at the block device layer.
> 
> The second is reiserfs-jh-1, which changes where the lists live for
> data=ordered and tail buffers.  It allows us to do a few things:

Hello all, I've updated the reiserfs-jh patch, it's now at
reiserfs-jh-2.  The major changes are tested O_DIRECT + data=ordered
support, and a bug fix for an oops under memory pressure.

In general the patch has had a few more hours of testing on it now, and
I'm less worried about it making your computer catch on fire if you give
it a try.

-chris

Re: udpated data logging available

[Christian Mayrhuber]

Am Montag, 23. Juni 2003 04:45 schrieb Chris Mason:
> On Wed, 2003-06-18 at 09:56, Chris Mason wrote:
> > Hello again,
> >
> > ftp.suse.com/pub/people/mason/patches/data-logging/2.4.21/experimental
> >
> > Has two additional patches.  The first is io-stalls-logging-6.diff,
> > which is very similar to the io stalling code I've been posting on the
> > linux kernel list.  It's unrelated to reiserfs really, and fixes some
> > fairness issues at the block device layer.
> >
> > The second is reiserfs-jh-1, which changes where the lists live for
> > data=ordered and tail buffers.  It allows us to do a few things:
>
> Hello all, I've updated the reiserfs-jh patch, it's now at
> reiserfs-jh-2.  The major changes are tested O_DIRECT + data=ordered
> support, and a bug fix for an oops under memory pressure.
>
> In general the patch has had a few more hours of testing on it now, and
> I'm less worried about it making your computer catch on fire if you give
> it a try.
>
> -chris

This patch does better than reiserfs-jh-1, though It didn't eat the data on my system.
I was unable to login as root (both tty and su) for about 2 minutes after system
boot with the -1 patch (data=ordered mode and root fs on software raid1).

2.4.21 + data_logging and 2.4.21+data_logging + reiserfs-jh-2 + io-stalls-logging-6 does not
show this behaviour.

The quota patches seem to work with the experimental data logging stuff, too.
The system latency is bad during heavy  io, but this could hold true for all of the 2.4.x kernel series.
You can try it yourself if you  issue the command "dd if=/dev/zero of=tst bs=102400" in a shell and
now try to start another app. (I did this to test the user quota.)
-- 
lg, Chris

Re: udpated data logging available

[Chris Mason]

On Mon, 2003-06-23 at 12:53, Christian Mayrhuber wrote:

> This patch does better than reiserfs-jh-1, though It didn't eat the data on my system.
> I was unable to login as root (both tty and su) for about 2 minutes after system
> boot with the -1 patch (data=ordered mode and root fs on software raid1).
> 
> 2.4.21 + data_logging and 2.4.21+data_logging + reiserfs-jh-2 + io-stalls-logging-6 does not
> show this behaviour.
> 
> The quota patches seem to work with the experimental data logging stuff, too.
> The system latency is bad during heavy  io, but this could hold true for all of the 2.4.x kernel series.
> You can try it yourself if you  issue the command "dd if=/dev/zero of=tst bs=102400" in a shell and
> now try to start another app. (I did this to test the user quota.)

Thanks for giving things a try.  I just uploaded io-stalls-7.diff, which
should do better at fixing latency during heavy io.

-chris

Re: udpated data logging available

[Christian Mayrhuber]

Am Mittwoch, 25. Juni 2003 21:15 schrieb Chris Mason:
> Thanks for giving things a try.  I just uploaded io-stalls-7.diff, which
> should do better at fixing latency during heavy io.
>
> -chris

My feeling is that io-stalls-6 is where standard 2.4.21 was if it comes down to latency.
But io-stalls-7 makes a big improvement for me during heavy io. The directory listing
in Konqueror, including image preview, appears nearly immedeately even during heavy io. 

Great work! Thanks.
-- 
lg, Chris

Re: udpated data logging available

[Chris Mason]

On Wed, 2003-06-25 at 20:16, Christian Mayrhuber wrote:
> Am Mittwoch, 25. Juni 2003 21:15 schrieb Chris Mason:
> > Thanks for giving things a try.  I just uploaded io-stalls-7.diff, which
> > should do better at fixing latency during heavy io.
> >
> > -chris
> 
> My feeling is that io-stalls-6 is where standard 2.4.21 was if it comes down to latency.
> But io-stalls-7 makes a big improvement for me during heavy io. The directory listing
> in Konqueror, including image preview, appears nearly immedeately even during heavy io. 

Great to hear, thanks for giving it a try.  io-stalls-6 helped most when
you've got multiple devices and a streaming write to one was slowing
down all the others.  -7 added in a tweaked form of Andrea's elevator
latency fixes, and they make a big difference when there's a lot of
writes to the drive you're trying to read from.

Hopefully we'll be able to hash out something suitable for 2.4.22-pre.

-chris

Re: udpated data logging available

[Dieter Nützel]

Am Donnerstag, 26. Juni 2003 03:47 schrieb Chris Mason:
> On Wed, 2003-06-25 at 20:16, Christian Mayrhuber wrote:
> > Am Mittwoch, 25. Juni 2003 21:15 schrieb Chris Mason:
> > > Thanks for giving things a try.  I just uploaded io-stalls-7.diff,
> > > which should do better at fixing latency during heavy io.
> > >
> > > -chris
> >
> > My feeling is that io-stalls-6 is where standard 2.4.21 was if it comes
> > down to latency. But io-stalls-7 makes a big improvement for me during
> > heavy io. The directory listing in Konqueror, including image preview,
> > appears nearly immedeately even during heavy io.
>
> Great to hear, thanks for giving it a try.  io-stalls-6 helped most when
> you've got multiple devices and a streaming write to one was slowing
> down all the others.  -7 added in a tweaked form of Andrea's elevator
> latency fixes, and they make a big difference when there's a lot of
> writes to the drive you're trying to read from.

So, does it apply to 2.4.21-aa1 (latest is 2.4.21rc8aa1) cleanly? ;-)

Setting HZ=1000 (from 100) in linux/include/asm/param.h give me very 
impressive latency boost. 2.4.21-rc1-jam1 (-rc1aa1)
Would you have some latencytest0.42-png numbers?

But ACPI will not shut down my SMP system (same with HZ=100) most of the time. 
I had it accidentally set to HZ=1024 and it power down all the time...;-)

> Hopefully we'll be able to hash out something suitable for 2.4.22-pre.

2.4.22-pre1 is out form some days...

Regards,
	Dieter

Re: udpated data logging available

[Chris Mason]

On Thu, 2003-06-26 at 07:42, Dieter Nützel wrote:

> > Great to hear, thanks for giving it a try.  io-stalls-6 helped most when
> > you've got multiple devices and a streaming write to one was slowing
> > down all the others.  -7 added in a tweaked form of Andrea's elevator
> > latency fixes, and they make a big difference when there's a lot of
> > writes to the drive you're trying to read from.
> 
> So, does it apply to 2.4.21-aa1 (latest is 2.4.21rc8aa1) cleanly? ;-)
> 

No, io-stalls-7 is mostly in rc8aa1 already.  The major difference is
that andrea changed blk_finished_io and I added a new func to keep
compatibility for external drivers.  There are a few areas where he and
I chose different ways of doing things, if you're interested in helping
add some measurements to our debate, I can make you a patch against aa1.

> > Hopefully we'll be able to hash out something suitable for 2.4.22-pre.
> 
> 2.4.22-pre1 is out form some days...

Yes.  Almost all my latency testing was done on data logging + the jh-2
patch, so I'm much more confident now in that code.  Hopefully the
merging will start shortly, Oleg has a queue of things he wants to get
in, and we're trying to keep the rate of changes at something
manageable.

(quick clarification, io-stalls-7 is entirely unrelated to reiserfs, I
posted it here because I thought there might be some willing testers ;-)

-chris

Re: udpated data logging available

[Manuel Krause]

On 06/26/2003 02:53 PM, Chris Mason wrote:
> On Thu, 2003-06-26 at 07:42, Dieter Nützel wrote:
> 
>>>Great to hear, thanks for giving it a try.  io-stalls-6 helped most when
>>>you've got multiple devices and a streaming write to one was slowing
>>>down all the others.  -7 added in a tweaked form of Andrea's elevator
>>>latency fixes, and they make a big difference when there's a lot of
>>>writes to the drive you're trying to read from.
>>
>>So, does it apply to 2.4.21-aa1 (latest is 2.4.21rc8aa1) cleanly? ;-)
>>
> 
> No, io-stalls-7 is mostly in rc8aa1 already.  The major difference is
> that andrea changed blk_finished_io and I added a new func to keep
> compatibility for external drivers.  There are a few areas where he and
> I chose different ways of doing things, if you're interested in helping
> add some measurements to our debate, I can make you a patch against aa1.
> 
>>>Hopefully we'll be able to hash out something suitable for 2.4.22-pre.
>>
>>2.4.22-pre1 is out form some days...
> 
> Yes.  Almost all my latency testing was done on data logging + the jh-2
> patch, so I'm much more confident now in that code.  Hopefully the
> merging will start shortly, Oleg has a queue of things he wants to get
> in, and we're trying to keep the rate of changes at something
> manageable.
> 
> (quick clarification, io-stalls-7 is entirely unrelated to reiserfs, I
> posted it here because I thought there might be some willing testers ;-)
> 
> -chris

Hi,

the complete data-logging patchset including the experimental ones is
running fine on here, kernel 2.4.21-final without quota, with
rml-preempt-kernel and with the "old" search_reada-4. It also ran fine
with the previous reiserfs-jh-1 and io-stalls-6 before.

Does the search_reada-4 contradict the new code or is it even dangerous
to combine them (what I luckily didn't trigger so far)?

Thanks,

 Manuel

Re: udpated data logging available

[Manuel Krause]

On 06/26/03 15:36, Manuel Krause wrote:
> On 06/26/2003 02:53 PM, Chris Mason wrote:
> 
>>On Thu, 2003-06-26 at 07:42, Dieter Nützel wrote:
>>
>>>>Great to hear, thanks for giving it a try.  io-stalls-6 helped most when
>>>>you've got multiple devices and a streaming write to one was slowing
>>>>down all the others.  -7 added in a tweaked form of Andrea's elevator
>>>>latency fixes, and they make a big difference when there's a lot of
>>>>writes to the drive you're trying to read from.
>>>
>>>So, does it apply to 2.4.21-aa1 (latest is 2.4.21rc8aa1) cleanly? ;-)
>>
>>No, io-stalls-7 is mostly in rc8aa1 already.  The major difference is
>>that andrea changed blk_finished_io and I added a new func to keep
>>compatibility for external drivers.  There are a few areas where he and
>>I chose different ways of doing things, if you're interested in helping
>>add some measurements to our debate, I can make you a patch against aa1.
>>
>>>>Hopefully we'll be able to hash out something suitable for 2.4.22-pre.
>>>
>>>2.4.22-pre1 is out form some days...
>>
>>Yes.  Almost all my latency testing was done on data logging + the jh-2
>>patch, so I'm much more confident now in that code.  Hopefully the
>>merging will start shortly, Oleg has a queue of things he wants to get
>>in, and we're trying to keep the rate of changes at something
>>manageable.
>>
>>(quick clarification, io-stalls-7 is entirely unrelated to reiserfs, I
>>posted it here because I thought there might be some willing testers ;-)
>>
>>-chris
> 
> Hi,
> 
> the complete data-logging patchset including the experimental ones is
> running fine on here, kernel 2.4.21-final without quota, with
> rml-preempt-kernel and with the "old" search_reada-4. It also ran fine
> with the previous reiserfs-jh-1 and io-stalls-6 before.
> 
> Does the search_reada-4 contradict the new code or is it even dangerous
> to combine them (what I luckily didn't trigger so far)?
> 
> Thanks,
> 
>  Manuel

No answer needed so far upon search_reada-4 ?!?!

If I may remind, that only patch brought 2.4.20+  +reiserfs
+data-logging to the high throughput values of 2.4.19 +reiserfs
+data-logging when copying my backup partition (around 5GB) via cp.



O.K. -- The new (experimental) patches run fine on all my previous
simple test patterns _with_ search_reada-4 (cp my backup-partitions,
home usage with NS 7.1 and OOo 1.1betas; VMware 3.2.1 sessions with
defrag/SpeedDisk in Win98) with 2.4.21 +data-logging +rml-preempt-kernel.

I didn't post definite timings upon my data as using the first new
experimental data-logging patches led to a throughput/speed improvement
of 3% only (compared to without exp patches) what is within in the
typical fluctuation (copying via cp). And I avoided testing without
search_reada so far, for the reason of needed retesting back to 2.4.19
(disk content changed).
So, at least, I can say "It didn't get slower - but may be a bit faster
or even another bit more. - Depends..."


Many thanks, your work is great indeed !

 Manuel

Re: udpated data logging available

[Chris Mason]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

On Tue, 2003-07-01 at 19:41, Manuel Krause wrote:
>  
> > Does the search_reada-4 contradict the new code or is it even dangerous
> > to combine them (what I luckily didn't trigger so far)?
> > 
> > Thanks,
> > 
> >  Manuel
> 
> No answer needed so far upon search_reada-4 ?!?!
> 

Sorry, I've been doing some final testing on search_reada-5, which is
attached.  It doesn't help quite as much as search_reada-4, but it also
doesn't hurt the random io case anywhere near as badly.  It tries to be
smarter about only doing read ahead for the same object you are
searching for.  

I'll upload in the morning.

> If I may remind, that only patch brought 2.4.20+  +reiserfs
> +data-logging to the high throughput values of 2.4.19 +reiserfs
> +data-logging when copying my backup partition (around 5GB) via cp.
> 
> 
> 
> O.K. -- The new (experimental) patches run fine on all my previous
> simple test patterns _with_ search_reada-4 (cp my backup-partitions,
> home usage with NS 7.1 and OOo 1.1betas; VMware 3.2.1 sessions with
> defrag/SpeedDisk in Win98) with 2.4.21 +data-logging +rml-preempt-kernel.
> 
> I didn't post definite timings upon my data as using the first new
> experimental data-logging patches led to a throughput/speed improvement
> of 3% only (compared to without exp patches) what is within in the
> typical fluctuation (copying via cp). And I avoided testing without
> search_reada so far, for the reason of needed retesting back to 2.4.19
> (disk content changed).
> So, at least, I can say "It didn't get slower - but may be a bit faster
> or even another bit more. - Depends..."
> 

Most of the improvement comes in fsync heavy workloads.  The
data=ordered io is a little smoother as well, for better latencies in
general.

> 
> Many thanks, your work is great indeed !
> 

Thanks for your continued tests, they are very helpful.

-chris


[-- Attachment #2: search_reada-5.diff --]
[-- Type: text/plain, Size: 3648 bytes --]

===== fs/reiserfs/stree.c 1.22 vs edited =====
--- 1.22/fs/reiserfs/stree.c	Mon Jun 30 12:45:49 2003
+++ edited/fs/reiserfs/stree.c	Mon Jun 30 13:33:02 2003
@@ -598,26 +598,32 @@
 
 
 
-#ifdef SEARCH_BY_KEY_READA
+#define SEARCH_BY_KEY_READA 8
 
 /* The function is NOT SCHEDULE-SAFE! */
-static void search_by_key_reada (struct super_block * s, int blocknr)
+static void search_by_key_reada (struct super_block * s, 
+                                 struct buffer_head **bh, 
+				 unsigned long *b, int num)
 {
-    struct buffer_head * bh;
+    int i,j;
   
-    if (blocknr == 0)
-	return;
-
-    bh = getblk (s->s_dev, blocknr, s->s_blocksize);
-  
-    if (!buffer_uptodate (bh)) {
-	ll_rw_block (READA, 1, &bh);
+    for (i = 0 ; i < num ; i++) {
+	bh[i] = sb_getblk (s, b[i]);
+	if (buffer_uptodate(bh[i])) {
+	    brelse(bh[i]);
+	    break;
+	}
+	touch_buffer(bh[i]);
+    } 
+    if (i) {
+	ll_rw_block(READA, i, bh);
+    }
+    for(j = 0 ; j < i ; j++) {
+        if (bh[j])
+	    brelse(bh[j]);
     }
-    bh->b_count --;
 }
 
-#endif
-
 /**************************************************************************
  * Algorithm   SearchByKey                                                *
  *             look for item in the Disk S+Tree by its key                *
@@ -660,6 +666,9 @@
     int				n_node_level, n_retval;
     int 			right_neighbor_of_leaf_node;
     int				fs_gen;
+    struct buffer_head *reada_bh[SEARCH_BY_KEY_READA];
+    unsigned long      reada_blocks[SEARCH_BY_KEY_READA];
+    int reada_count = 0;
 
 #ifdef CONFIG_REISERFS_CHECK
     int n_repeat_counter = 0;
@@ -696,11 +705,11 @@
 	fs_gen = get_generation (p_s_sb);
 	expected_level --;
 
-#ifdef SEARCH_BY_KEY_READA
-	/* schedule read of right neighbor */
-	search_by_key_reada (p_s_sb, right_neighbor_of_leaf_node);
-#endif
-
+	/* schedule read of right neighbors */
+	if (reada_count) {
+	    search_by_key_reada (p_s_sb, reada_bh, reada_blocks, reada_count);
+	    reada_count = 0;
+	}
 	/* Read the next tree node, and set the last element in the path to
            have a pointer to it. */
 	if ( ! (p_s_bh = p_s_last_element->pe_buffer =
@@ -787,12 +796,37 @@
 	   an internal node.  Now we calculate child block number by
 	   position in the node. */
 	n_block_number = B_N_CHILD_NUM(p_s_bh, p_s_last_element->pe_position);
-
-#ifdef SEARCH_BY_KEY_READA
-	/* if we are going to read leaf node, then calculate its right neighbor if possible */
-	if (n_node_level == DISK_LEAF_NODE_LEVEL + 1 && p_s_last_element->pe_position < B_NR_ITEMS (p_s_bh))
-	    right_neighbor_of_leaf_node = B_N_CHILD_NUM(p_s_bh, p_s_last_element->pe_position + 1);
-#endif
+	
+	/* if we are going to read leaf nodes, try for read ahead as well */
+	if (n_node_level == DISK_LEAF_NODE_LEVEL + 1 && 
+	    p_s_last_element->pe_position < B_NR_ITEMS (p_s_bh) &&
+	    !is_direct_cpu_key(p_s_key) && 
+	    !is_statdata_cpu_key(p_s_key))
+	{
+	    int pos = p_s_last_element->pe_position;
+	    int limit = B_NR_ITEMS(p_s_bh);
+	    struct buffer_head *tmp_bh;
+	    struct key *le_key;
+
+	    /* don't try to readahead if the leaf is already
+	     * in ram.  get_hash_table doesn't schedule, so this
+	     * is safe
+	     */
+	    tmp_bh = sb_get_hash_table(p_s_sb, n_block_number);
+	    if (tmp_bh) {
+	        brelse(tmp_bh);
+		continue;
+	    }
+	    while(pos <= limit && reada_count < SEARCH_BY_KEY_READA) { 
+		le_key = B_N_PDELIM_KEY(p_s_bh, pos);
+		if (le32_to_cpu(le_key->k_objectid) != 
+		    p_s_key->on_disk_key.k_objectid)
+		{
+		    break;
+		}
+	        reada_blocks[reada_count++] = B_N_CHILD_NUM(p_s_bh, pos++);
+	    }
+        }
     }
 }
 

Re: udpated data logging available

[Dieter Nützel]

Am Donnerstag, 26. Juni 2003 14:53 schrieb Chris Mason:
> On Thu, 2003-06-26 at 07:42, Dieter Nützel wrote:
> > > Great to hear, thanks for giving it a try.  io-stalls-6 helped most
> > > when you've got multiple devices and a streaming write to one was
> > > slowing down all the others.  -7 added in a tweaked form of Andrea's
> > > elevator latency fixes, and they make a big difference when there's a
> > > lot of writes to the drive you're trying to read from.
> >
> > So, does it apply to 2.4.21-aa1 (latest is 2.4.21rc8aa1) cleanly? ;-)
>
> No, io-stalls-7 is mostly in rc8aa1 already.  The major difference is
> that andrea changed blk_finished_io and I added a new func to keep
> compatibility for external drivers.  There are a few areas where he and
> I chose different ways of doing things, if you're interested in helping
> add some measurements to our debate, I can make you a patch against aa1.

Yes, please.
Should I start with rc8aa1 or does Andrea have something newer?

-Dieter

Re: udpated data logging available

[Manuel Krause]

On 06/26/2003 01:42 PM, Dieter Nützel wrote:
> Am Donnerstag, 26. Juni 2003 03:47 schrieb Chris Mason:
> 
>>On Wed, 2003-06-25 at 20:16, Christian Mayrhuber wrote:
>>
>>>Am Mittwoch, 25. Juni 2003 21:15 schrieb Chris Mason:
>>>
>>>>Thanks for giving things a try.  I just uploaded io-stalls-7.diff,
>>>>which should do better at fixing latency during heavy io.
>>>>
>>>>-chris
>>>
>>>My feeling is that io-stalls-6 is where standard 2.4.21 was if it comes
>>>down to latency. But io-stalls-7 makes a big improvement for me during
>>>heavy io. The directory listing in Konqueror, including image preview,
>>>appears nearly immedeately even during heavy io.
>>
>>Great to hear, thanks for giving it a try.  io-stalls-6 helped most when
>>you've got multiple devices and a streaming write to one was slowing
>>down all the others.  -7 added in a tweaked form of Andrea's elevator
>>latency fixes, and they make a big difference when there's a lot of
>>writes to the drive you're trying to read from.
> 
> So, does it apply to 2.4.21-aa1 (latest is 2.4.21rc8aa1) cleanly? ;-)
> 
> Setting HZ=1000 (from 100) in linux/include/asm/param.h give me very 
> impressive latency boost. 2.4.21-rc1-jam1 (-rc1aa1)

Just tried this HZ=1000 setting, too.

(With the following patches "only": data-logging, search_reada-4 and
rml-preempt on 2.4.21-final, and AA.00_nanosleep-6.diff (THAT ONE
decreased my VMware+system CPU idle usage in these circumstances by
approx. 1/2 [from 25% to approx. 12.5%] ).

I don't get any performance boost with it -- but some finer distribution
of "requests"  like from disk i/o, screen interaction
(XF86-4.3.0-SuSE-8.0) and running applications' progress together with
high mem/disk load (the result is my word for "finer granularity" in
computer usage). That setting feels much better than normal (HZ=100).

Would I face problems, though?! Why isn't that setting standard ?

> Would you have some latencytest0.42-png numbers?
> 
> But ACPI will not shut down my SMP system (same with HZ=100) most of the time. 
> I had it accidentally set to HZ=1024 and it power down all the time...;-)
> 
>>Hopefully we'll be able to hash out something suitable for 2.4.22-pre.
> 
> 2.4.22-pre1 is out form some days...
> 
> Regards,
>   Dieter

Thanks,

 Manuel

--
@ list.ReiserFS: I need to change my mail address from:
 manuel.krause @AT *.tu-ilmenau.de
to:
 manuelkrause @AT netscape.net
-
 Change @AT and the spaces to get contact.

Re: udpated data logging available

[Chris Mason]

On Tue, 2003-07-01 at 20:46, Manuel Krause wrote:
>  
> > Setting HZ=1000 (from 100) in linux/include/asm/param.h give me very 
> > impressive latency boost. 2.4.21-rc1-jam1 (-rc1aa1)
> 
> Just tried this HZ=1000 setting, too.
> 
> (With the following patches "only": data-logging, search_reada-4 and
> rml-preempt on 2.4.21-final, and AA.00_nanosleep-6.diff (THAT ONE
> decreased my VMware+system CPU idle usage in these circumstances by
> approx. 1/2 [from 25% to approx. 12.5%] ).
> 

Some userspace tools depend on the HZ value.  It's clear the io-stalls-7
patch can't be the final one, I need to add userspace knobs to tune
things towards latency or multi-writer throughput (basically server or
desktop workloads).

-chris

Re: udpated data logging available

[Dieter Nützel]

Can someone resend me a copy of reiserfs-jh-2, please?

Thanks,
	Dieter

Re: udpated data logging available

[Philippe Gramoullé]

Hello Dieter,

ftp.suse.com:/pub/people/mason/patches/data-logging/2.4.21/experimental/06-reiserfs-jh-2.diff.gz

Thanks,

Philippe

On Thu, 26 Jun 2003 13:48:17 +0200
Dieter Nützel <Dieter.Nuetzel@hamburg.de> wrote:

  | Can someone resend me a copy of reiserfs-jh-2, please?
  | 
  | Thanks,
  | 	Dieter
  | 

Re: udpated data logging available

[Dieter Nützel]

Am Donnerstag, 26. Juni 2003 14:18 schrieb Philippe Gramoullé:
> Hello Dieter,
>
> ftp.suse.com:/pub/people/mason/patches/data-logging/2.4.21/experimental/06-
>reiserfs-jh-2.diff.gz

Thanks, but this is weird.

If I go after Chris's "second" posted link above it isn't there, but after his 
first and yours it is...?

Maybe some server updating problems at SuSE?

Anyway I got it;-)

-Dieter