Re: svn commit: r184471 - in head/bin: cat cp

[ Available lists | Index of svn-src-head | Month of Nov 2008 | Week of 2 Nov 2008 | Raw email | View thread | Wrap long lines | Reply ]
From
Ivan Voras <ivoras@freebsd.org>
Date
2 Nov 2008 23:34:49
Subject
Re: svn commit: r184471 - in head/bin: cat cp
Message-ID
9bbcef730811021534gb114db9x16a2d6c9a3ecee8b@mail.gmail.com


[ Hide this part ]
2008/10/31 Giorgos Keramidas <keramida@freebsd.org>:

> Nice :)
>
> I didn't notice this in -hackers, but it may be worth letting the buffer
> size grow above 1 MB when we have more than, say, 512 MB of memory. By
> running dd(1) with buffer sizes of 1, 2, 4, 6, 8, 10, 12, 14, and 16 MB
> there are larger buffer sizes that reduce involuntary context switches
> even more.
>
> My laptop (with more than 2 GB or memory), with powerd disabled, running
> in single user mode, and copying a file of 200 MB using the script:
>...
> got the following results for sizes < 10 MB:
>...

As I read it, for x memory you have y context switches:

64 kB - 11194 (old, pre-patch behaviour)

1 MB - 1493
2 MB - 1381
4 MB - 1342
6 MB - 1292
8 MB - 1275
16 MB - 1246

The difference between the best and the worst is 247 context switches
(total, not per second).

> It looks like it's probably worth pushing the limit up to 8 MB when we
> have lots of memory :)

Yes, it's an improvement, but who will ever notice? :)

I have no strong reason against increasing the buffer for cp to even 8
MB but I really think it's not worth it at this point. In the patch,
I've actually allowed the buffer size to grow to 2 MB if MAXPHYS ever
gets bumped up (and would gladly increase *this* limit up). I think
that, at this point, increasing MAXPHYS will give better performance
than increasing this particular buffer.

Elapsed time: 0.208 seconds