Speedup patch for 2.4.19-pre6 in bitmap.c

Speedup patch for 2.4.19-pre6 in bitmap.c

[Philippe Gramoulle]

Hi Oleg,

As you seem to find the list quite calm, i will try to set a little bit of animation :o)

Here it goes: 

i'm trying to set up a 2.4.19-pre6 kernel with the following patches:

- NFS linux-2.4.19-NFS_ALL.dif  for pre6
- linux-2.4.19-12-neilb.dif     for pre6 for NFSv3 TCP

- Quota patches :
  - quota-v2-2.4.19-pre3: Jan Kara's v2 quota code
  - dquot_deadlock.diff.gz
  - nesting-10-2.4.19-pre3.diff.gz
  - reiserfs-quota-22.diff.gz
  - kinoded-8-2.4.19-pre3.diff.gz

- fs/dquot.c : change in sys_quotactl : remove the 
	       if (id & ~0xFFFF)
                goto out;
	       for 32 bits UIDs

- speedup patch for 2.4.19-pre6 recently posted to the list.


Patches apply correctly except one reject in bitmap.c when applying the speedup patch.

Here is the bitmap.c.rej:

***************
*** 122,128 ****
    set_sb_free_blocks( rs, sb_free_blocks(rs) + 1 );
  
    journal_mark_dirty (th, s, sbh);
-   s->s_dirt = 1;
  }
  
  void reiserfs_free_block (struct reiserfs_transaction_handle *th, 
--- 122,127 ----
    set_sb_free_blocks( rs, sb_free_blocks(rs) + 1 );
  
    journal_mark_dirty (th, s, sbh);
  }
  
  void reiserfs_free_block (struct reiserfs_transaction_handle *th, 

because of the addition from reiserfs-quota-22.diff :

+  if (for_unformatted) {
+#ifdef REISERQUOTA_DEBUG
+    printk(KERN_DEBUG "reiserquota: freeing block id=%u\n", inode->i_uid);
+#endif
+    DQUOT_FREE_BLOCK_NODIRTY(inode, 1);
+  }

Is this something i can blindly update by hand ,i mean manually remove "s->s_dirt = 1;" ?

I'll do so in the meantime and test it on our test bed system.

At the moment i'm pretty surprised by the NFSv3 TCP performance:
( 6.32 Mb/s for a single dd if=/dev/zero of =testfile bs=8192 count=25000 , 200Mb file)
( average of 460 Kb/s when uploading a 184Mo compiled kernel tree through FTP)

Before that i manage to get 10Mb/s on an eepro100 with vanilla 2.4.18 and NFS_ALL TCP from Trond
(either NFSv3 TCP or UDP)

Thanks,

Philippe.

PS: NFS server and client are Linux boxes running 2.4.18 and above kernel (from the 2.4.x series) both fully
reiserfs'ified

Re: Speedup patch for 2.4.19-pre6 in bitmap.c

[Oleg Drokin]

Hello!

On Wed, Apr 10, 2002 at 04:55:08PM +0200, Philippe Gramoulle wrote:

> Here is the bitmap.c.rej:
> -   s->s_dirt = 1;

> Is this something i can blindly update by hand ,i mean manually remove "s->s_dirt = 1;" ?

Yes, just remove that line manually.

> At the moment i'm pretty surprised by the NFSv3 TCP performance:
> ( 6.32 Mb/s for a single dd if=/dev/zero of =testfile bs=8192 count=25000 , 200Mb file)
> ( average of 460 Kb/s when uploading a 184Mo compiled kernel tree through FTP)
> 
> Before that i manage to get 10Mb/s on an eepro100 with vanilla 2.4.18 and NFS_ALL TCP from Trond
> (either NFSv3 TCP or UDP)

So I assume you are negatively surprised, right?
And if you undo the speedup patch only, do you get your numbers back?
Also do you have highmem on for 2.4.19-pre6 kernel?

Bye,
    Oleg

Re: Speedup patch for 2.4.19-pre6 in bitmap.c

[Philippe Gramoulle]

Hi Oleg,

> So I assume you are negatively surprised, right?
> And if you undo the speedup patch only, do you get your numbers back?
> Also do you have highmem on for 2.4.19-pre6 kernel?

Sorry for the confusion :

With 2.4.18 + TCP patch => 10Mb/s
Now witout the speedup patch and with a 2.4.19-pre6 + the patches i've listed => 6.32 Mb/s NFS TCP

That's why i want to give your speedup patch a try !! :o)

i'll redo the test, time for me to rebuild the kernel with the speedup patch and redo the tests, say 15minutes.

I' send the figures then.

Thanks,

Philippe.

Re: Speedup patch for 2.4.19-pre6 in bitmap.c

[Oleg Drokin]

Hello!

On Wed, Apr 10, 2002 at 05:09:19PM +0200, Philippe Gramoulle wrote:

> > So I assume you are negatively surprised, right?
> > And if you undo the speedup patch only, do you get your numbers back?
> > Also do you have highmem on for 2.4.19-pre6 kernel?
> Sorry for the confusion :
> With 2.4.18 + TCP patch => 10Mb/s
> Now witout the speedup patch and with a 2.4.19-pre6 + the patches i've listed => 6.32 Mb/s NFS TCP

> That's why i want to give your speedup patch a try !! :o)

Ah. So my question remains, do you have highmem enabled? If you do,
also try without highmem with and without speedup patches.
Number of peoples raised a question about Andrea Archangelli's patch
that went into 2.4.19-pre5 to improve I/O throughtput wrt several allocation
zones.
I myself see throughtput decrease with highmem on.

> i'll redo the test, time for me to rebuild the kernel with the speedup patch and redo the tests, say 15minutes.
> I' send the figures then.

Ok. Thank you.

Bye,
    Oleg

Re: Speedup patch for 2.4.19-pre6 in bitmap.c

[Philippe Gramoulle]

On Wed, Apr 10, 2002 at 07:13:56PM +0400, Oleg Drokin wrote:
> Hello!
> 
> On Wed, Apr 10, 2002 at 05:09:19PM +0200, Philippe Gramoulle wrote:
> 
> > > So I assume you are negatively surprised, right?
> > > And if you undo the speedup patch only, do you get your numbers back?
> > > Also do you have highmem on for 2.4.19-pre6 kernel?
> > Sorry for the confusion :
> > With 2.4.18 + TCP patch => 10Mb/s
> > Now witout the speedup patch and with a 2.4.19-pre6 + the patches i've listed => 6.32 Mb/s NFS TCP
> 
> > That's why i want to give your speedup patch a try !! :o)
> 
> Ah. So my question remains, do you have highmem enabled? If you do,
> also try without highmem with and without speedup patches.

Yep , i forgot to answer your question :-(

Yes Higmem is enabled.

As you suggested, i'll try with and without the speedup patch as well as with and
without Highmem.

> Number of peoples raised a question about Andrea Archangelli's patch
> that went into 2.4.19-pre5 to improve I/O throughtput wrt several allocation
> zones.
> I myself see throughtput decrease with highmem on.

As a reminder here is the test with no speedup patch and Highmem on:
time dd if=/dev/zero of=test1 bs=8192 count=25000
25000+0 records in
25000+0 records out

real    0m32.182s
user    0m0.020s
sys     0m1.530s

Now with the speedup patch and still highmem on:

time dd if=/dev/zero of=test2 bs=8192 count=25000
25000+0 records in
25000+0 records out

real    0m41.149s
user    0m0.000s
sys     0m0.920s

With the speedup patch and highmem off:

time dd if=/dev/zero of=zobada bs=8192 count=25000
e25000+0 records in             
25000+0 records out             
                                
real    0m40.390s               
user    0m0.020s                
sys     0m1.070s              

I'll send the missing test ( without speedup patch and without Highmem) later tonight.

Thanks,

Philippe.

PS: i'll also redo some tests with 2.4.18 +NFS_ALL and try with UDP as well.

Re: Speedup patch for 2.4.19-pre6 in bitmap.c

[Oleg Drokin]

Hello!

On Wed, Apr 10, 2002 at 08:48:48PM +0200, Philippe Gramoulle wrote:
 
> I'll send the missing test ( without speedup patch and without Highmem) later tonight.
> PS: i'll also redo some tests with 2.4.18 +NFS_ALL and try with UDP as well.

Ok. Can you also try to measure writing speed without NFS in between?
(like dd if=/dev/zero of=/localfs/file ...)
With and without speedup & highmem

Thank you.

Bye,
    Oleg

Re: Speedup patch for 2.4.19-pre6 in bitmap.c

[Philippe Gramoulle]

On Wed, Apr 10, 2002 at 11:05:27PM +0400, Oleg Drokin wrote:
> Hello!
> 
> On Wed, Apr 10, 2002 at 08:48:48PM +0200, Philippe Gramoulle wrote:
>  
> > I'll send the missing test ( without speedup patch and without Highmem) later tonight.
> > PS: i'll also redo some tests with 2.4.18 +NFS_ALL and try with UDP as well.
> 
> Ok. Can you also try to measure writing speed without NFS in between?
> (like dd if=/dev/zero of=/localfs/file ...)
> With and without speedup & highmem
> 
> Thank you.
> 
> Bye,
>     Oleg

Yes , i'll do that.

Hopefully , i should be done with all tests tomorrow.

Thanks,

Philippe.

Re: Speedup patch for 2.4.19-pre6 in bitmap.c

[wolfgang.glas]

Dear Philippe,

   Reduced NFS performance goes hand in hand with short network stalls on 
our server.

So it would be helpful, if you could nmonitor your network performance 
with a tool like ksysguard showing you the time-dependancy of the network 
throughput. I bet, that you run into network stalls for around 1s, when 
your average performance is diminished.

  Regards,
 
    Wolfgang

--
Dr. Wolfgang Glas                        EV-i Informationstechnologie 
GmbH.
Geschäftsführer                          Sebastian-Kneipp-Weg 17
Wolfgang.Glas@ev-i.at                    A-6020 Innsbruck/Austria
phone: ++43-512-284883-2                 fax: ++43-512-281624-31