[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HFS Patch 15 out
From: |
Szakacsits Szabolcs |
Subject: |
Re: HFS Patch 15 out |
Date: |
Mon, 27 Sep 2004 13:17:20 +0200 (MEST) |
On Fri, 24 Sep 2004, K.G. wrote:
> I've rewritten the search algorithm using a cache storing extent
> references of the FS in a sorted order, but this has not resulted in
> the spectacular speed improvement I expected. I've found that most
> (indeed nearly all) CPU time is spent in kernel space so I will try to
> understand why
On most of todays commodity hardwares the disk IO (speed and seek) should
be the bottleneck. For example, if I see it right, you use a lot sync's.
That's definitely a big performance killer, the kernel can't merge,
optimize disk IO and often the resize process just blocks waiting for IO.
Here are two ntfsresize timings (for relocating 3 GB) using in sync
intensive (data should be consistent even in case of power outage) and
less sync intensive mode (data might be corrupt in case of power outage):
8.43s usr, 46.85s sys, 179.16s real, 30% CPU <-- careful sync's
39.16s usr, 59.76s sys, 843.82s real, 11% CPU <-- lot of sync's
In this case, careful sync gave almost 5x speedup.
Ntfsresize's block allocator also tries to minimize disk seeks thus the
kernel can merge the IO write request.
> and find new solutions to accelerate things.
Doing it efficiently _and_ safely from user space can be somehow
complicated because the kernel doesn't provide the needed support,
nor it exports needed functionality (e.g. setting write barriers).
Szaka