[9fans] kfs performance

[9fans] kfs performance

[David Tolpin]

It takes three times more time to write a file under Plan9 
than under FreeBSD on the same computer (bunzip2 cdinstall.iso.bz2
, 200 Mb unzipped).

Is there something wrong with my setup, or is it normal?

David

Re: [9fans] kfs performance

[matt]

sounds normal for kfs

m

Re: [9fans] kfs performance

[ron minnich]

On Tue, 2 Mar 2004, David Tolpin wrote:

> 
> It takes three times more time to write a file under Plan9 
> than under FreeBSD on the same computer (bunzip2 cdinstall.iso.bz2
> , 200 Mb unzipped).
> 
> Is there something wrong with my setup, or is it normal?

are you sure you have dma on in plan 9?

ron

Re: [9fans] kfs performance

[gdiaz]

Hello,

I think there are threads on 9fan arhives about that topic, maybe 
it helps you. Take a look at groups.google.com ;),if i remeber correctly
you can add tunning parameters to increase performance (not sure about that).


BTW, i prefer to use fossil/venti as my thinkpad fileserver.


gabi

> It takes three times more time to write a file under Plan9 
> than under FreeBSD on the same computer (bunzip2 cdinstall.iso.bz2
> , 200 Mb unzipped).
> 
> Is there something wrong with my setup, or is it normal?
> 
> David

Re: [9fans] kfs performance

[Russ Cox]

> It takes three times more time to write a file under Plan9 
> than under FreeBSD on the same computer (bunzip2 cdinstall.iso.bz2
> , 200 Mb unzipped).
> 
> Is there something wrong with my setup, or is it normal?

this is pretty normal.  kfs isn't batching disk writes or paying
attention to disk layout, so you get what you get.  i bet that
freebsd is a bit more clever with its disk.  i'm surprised it's only
a factor of three.   fossil isn't any better in this regard, although
it does buffer more.

disk file system speed is one area where i do wish plan 9 was
zippier (as opposed to context switches betwen threads).

russ

Re: [9fans] kfs performance

[Jeff Sickel]

On Mar 2, 2004, at 8:19 PM, Russ Cox wrote:
>
> disk file system speed is one area where i do wish plan 9 was
> zippier (as opposed to context switches betwen threads).

Well, if you know of a grad program, preferably around Chicago, that 
would be willing to grant someone a degree for working on a particular 
improvement, I'd be glad to hear of it.

jas

Re: [9fans] kfs performance

[Charles Forsyth]

be sure that rwm is on too as well as dma.

>>freebsd is a bit more clever with its disk.  i'm surprised it's only
>>a factor of three.   fossil isn't any better in this regard, although
>>it does buffer more.

i'm not sure about current BSD or Linux come to that but in the past i found that
performance differences were often affected by the following as well:
	- not actually writing to the storage until much later
	- using most of memory as a big cache
the former isn't so good if you suddenly halt the machine (soft updates or no)
and the latter isn't so good if you need the memory for something else.
i suspect BSD does both.  of course, NOT doing them is unhelpful
if you're trying to write quickly.   furthermore, if you stop
the machine suddenly, clearly unwritten material won't be there
regardless whether you buffer a lot or a little (unless it has got heaps of NVRAM).
on PCs, i'd add `using the hardware effectively',
which plan 9 makes optional, presumably because rwm and dma might be
touchy on some chipsets(?).  don't know.
cache only helps reads?  not entirely: it means it can buffer that much
more before actually writing.

kfs is more diligent than the /sys/src/fs about forcing writes through
to disc.  that includes indirect blocks, i think, so all in all it will be
doing much more writing than either fs or BSD.  as rsc suggests that will also be in relatively
small amounts, although i'm not sure there's much difference with BSD there.
you could try switching that off to see what difference it makes.

to speed things up generally, you might also try
increasing the kfs cache if you've got lots of physical memory.
it uses 10% by default.  the -B option controls it.
bigger blocks help too.

Re: [9fans] kfs performance

[David Tolpin]

> to speed things up generally, you might also try

Yes, thank you, very useful. To clarify, I am not going
to race with FreeBSD or Linux; I was just checking whether
everything was ok with my setup or it was a sign of a problem.

As far as it is expected, I do not care; it is fast enough.

David

Re: [9fans] kfs performance

[matt]

> presumably because rwm and dma might be touchy on some chipsets(?)

I have a controller that doesn't like 'dma on' in my old pentium

m

Re: [9fans] kfs performance

[matt]

freebsd is also probably running ufs with soft updates turned on

"For metadata intensive benchmarks this improves performance by more than a factor of two when compared to the conventional syncronous write approach"

see 

hget http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/CSE-TR-254-95.ps | page 


m

Re: [9fans] kfs performance

[David Tolpin]

> freebsd is also probably running ufs with soft updates turned on

No, it is not probable. I was testing with soft updates turned off.

Re: [9fans] kfs performance

[Russ Cox]

> "For metadata intensive benchmarks this improves performance by more than a f
> actor of two when compared to the conventional syncronous write approach"
> 
> hget http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/CSE-TR-254-95.ps

except that extracting a 200MB file is anything but metadata intensive.

Re: [9fans] kfs performance

[C H Forsyth]

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

direct and indirect block pointers count as Bimm metadata to kfs,
so those writes are synchronous and as slow as the device.

[-- Attachment #2: Type: message/rfc822, Size: 2182 bytes --]

From: "Russ Cox" <rsc@swtch.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] kfs performance
Date: Wed, 03 Mar 2004 14:15:08 -0500
Message-ID: <E1Aybpo-000Fug-UQ@t40.swtch.com>

> "For metadata intensive benchmarks this improves performance by more than a f
> actor of two when compared to the conventional syncronous write approach"
> 
> hget http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/CSE-TR-254-95.ps

except that extracting a 200MB file is anything but metadata intensive.