> > The problem is that writing to a DVD-RAM, ZIP or MO device almost
> > totally blocks reading from a _different_ device. Here is some data.
> >
> > nr bench read write 2.4.18 2.4.19-rc5 expected factor
> > 1 dd 30GB HDD DVD-RAM 278 490 60 8.2
> > 2 dd 120GB HDD DVD-RAM 197 438 32 14
> > 3 dd 30GB HDD ZIP 158 239 60 4.0
> > 4 dd 120GB HDD ZIP 142 249 32 7.8
> > 5 dd 30GB HDD 120GB HDD 87 89 60 1.5
> > 6 dd 120GB HDD 30GB HDD 66 69 32 2.2
> > 7 cp 30GB HDD 120GB HDD 97 77 60 1.3
> > 8 cp 120GB HDD 30GB HDD 78 65 50 1.3
> >
> > The columns 2.4.18 and 2.4.19-rc5 list execution times in seconds of
> > the respective benchmark. The column "expected" lists the time I would
> > have expected for the respective benchmark to complete with a
> > "perfect" kernel. The "factor" is the factor 2.4.19-rc5 is slower than
> > a perfect kernel would be.
> The reason hd is faster is because new algorithm is much better than the
> previous mainline code. Now the reason the DVDRAM hangs the machine
> more, that's probably because more ram can be marked dirty with those
> new changes (beneficial for some workload, but it stalls much more the
> fast hd, if there's one very slow blkdev in the system). You can try
> decrasing the percent of vm dirty in the system with:
>
> echo 2 500 0 0 500 3000 3 1 0 >/proc/sys/vm/bdflush
Judging from the performance regression above it would seem the
new defaults suck rocks.
Can we please stop optimising Linux for a single workload benchmark
and start tuning it for the common case of running multiple kinds
of applications and making sure one application can't mess up the
others ?
Personally I couldn't care less if my tar went 30% faster if it
meant having my desktop unresponsive for the whole time.
regards,
Rik
-- http://www.linuxsymposium.org/2002/ "You're one of those condescending OLS attendants" "Here's a nickle kid. Go buy yourself a real t-shirt"http://www.surriel.com/ http://distro.conectiva.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/