linux-kernel - Re: Abysmal disk performance, how to debug?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 20 Jan 2007 21:05:15 +0100
From:	Willy Tarreau <w@....eu>
To:	Sunil Naidu <akula2.shark@...il.com>
Cc:	Ismail Dönmez <ismail@...dus.org.tr>,
	linux-kernel@...r.kernel.org
Subject: Re: Abysmal disk performance, how to debug?

On Sun, Jan 21, 2007 at 01:14:41AM +0530, Sunil Naidu wrote:
> On 1/20/07, Willy Tarreau <w@....eu> wrote:
> >> > >
> >
> >It is not expected to increase write performance, but it should help
> >you do something else during that time, or also give more responsiveness
> >to Ctrl-C. It is possible that you have fast and slow RAM, or that your
> >video card uses shared memory which slows down some parts of memory
> >which are not used anymore with those parameters.
> 
> I did test some SATA drives, am getting these value for 2.6.20-rc5:-
> 
> [sukhoi@...hoon ~]$ time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB) copied, 21.0962 seconds, 50.9 MB/s
> 
> What can you suggest here w.r.t my RAM & disk?

I don't suggest anything, this is already very good. The only goal of
reducing memory write cache is to get a more responsive system when
dumping massive amounts of data to disks, like above, because when
the system starts flushing the caches, you can only wait for it to
finish. But those tests are not realistic loads. A desktop and most
servers will benefit from large caches. But *some* workloads will
benefit from smaller caches if they consist in writing continuous
streams (eg: tcpdump or video recorders). What I suggested to the
user above was a way to get the system more responsive during his
test. It should not have changed the throughput at all if the
hardware was not a bit strange (well, it's a VAIO after all, I've
had one too, fortunately it died one month after the warranty,
putting an end to all my problems...).

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/