Roland McGrath <[EMAIL PROTECTED]> writes:
> You are atypical. On my system, for any given build I do, all the files
> fit in core and are already in the cache if I've done a previous compile
> recently, and the only disk activity is writing of new bits that the
> computation rarely blocks on.
Jeroen Dekkers <[EMAIL PROTECTED]> writes:
> But I was talking about a filesystem where it doesn't matter if there
> is data loss in the case of a crash. For example, I wouldn't care if
> the data of my glibc build is lost or corrupted. In that case we don't
> need it and providing an option whic
On Sat, May 04, 2002 at 03:06:58PM -0700, Thomas Bushnell, BSG wrote:
> Jeroen Dekkers <[EMAIL PROTECTED]> writes:
>
> > Sorry for my stupidity, but I don't see why fsck can't remove the
> > corrupted part and replace it with some sane stuff. It knows how the
> > filesystem should look like, so i
> I have found that compiling is a disk-bound activity since about
> 1988, on every system I've used...When I build a Linux kernel, the
> disk is continuously bumping along.
You are atypical. On my system, for any given build I do, all the files
fit in core and are already in the cache if I've d
Jeroen Dekkers <[EMAIL PROTECTED]> writes:
> Sorry for my stupidity, but I don't see why fsck can't remove the
> corrupted part and replace it with some sane stuff. It knows how the
> filesystem should look like, so it can change it so that it will look
> like that. Could you please explain why t
[EMAIL PROTECTED] (Niels Möller) writes:
> Right, it would improve the speed significantly, but it wouldn't get
> rid of the "harddisk is thrashing hard all the time while I'm
> compiling, even if I have plenty of RAM and all the source files are
> cached"-behaviour.
I have found that compiling
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> [EMAIL PROTECTED] (Niels Möller) writes:
>
> > I guess I should have asked for the ratio B/A. If that's small, as you
> > claim, there should be a significant gain. _If_ it turned out that A
> > and B were of the same size, then the gain would b
On Sat, May 04, 2002 at 02:11:48PM -0700, Thomas Bushnell, BSG wrote:
> Jeroen Dekkers <[EMAIL PROTECTED]> writes:
>
> > > The bugs that happen are *not* merely that you lose occasional object
> > > files. You can get arbitrary corruption.
> >
> > And then fsck can repair that in the case of a
Jeroen Dekkers <[EMAIL PROTECTED]> writes:
> > The bugs that happen are *not* merely that you lose occasional object
> > files. You can get arbitrary corruption.
>
> And then fsck can repair that in the case of a crash, right?
No.
The normal rules--the ones that I describe as "bug free" keep
[EMAIL PROTECTED] (Niels Möller) writes:
> I guess I should have asked for the ratio B/A. If that's small, as you
> claim, there should be a significant gain. _If_ it turned out that A
> and B were of the same size, then the gain would be quite small,
> decreasing the number of required syncs at
On Sat, May 04, 2002 at 01:22:58PM -0700, Thomas Bushnell, BSG wrote:
> Jeroen Dekkers <[EMAIL PROTECTED]> writes:
>
> > I think that for compilation we don't need to synchronize everything
> > to be sure the filesystem the compilation happens on has an
> > inconsistent. It doesn't really matter
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I'm quite sure it would help a lot.
Ok, that's good to know.
> Number (A) is quite large. Number (B), which is the case you asked
> about, is quite small.
I guess I should have asked for the ratio B/A. If that's small, as you
claim, there sho
[EMAIL PROTECTED] (Niels Möller) writes:
> I'd like to know if implementing the new scheme would really help
> making the statement "The Hurd is significantly slower than Linux for
> things like big compiles" false. If it's an optimization that's worth
> the effort.
I'm quite sure it would help
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> [EMAIL PROTECTED] (Niels Möller) writes:
>
> > Does anybody have any idea how often this case occurs with typical
> > activities like compilation?
>
> What's the point of the question: to decide if we can ignore the
> issue, or to decide if the
Jeroen Dekkers <[EMAIL PROTECTED]> writes:
> I think that for compilation we don't need to synchronize everything
> to be sure the filesystem the compilation happens on has an
> inconsistent. It doesn't really matter if you lose some objects
> files. Maybe it would be a nice thing to provide this
On Sat, May 04, 2002 at 08:34:20PM +0200, Niels M?ller wrote:
> Thanks for the explanation. I'm trying to understand what consequences
> for performance can be expected.
>
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > There are cases (as noted before) where the following sequence aris
[EMAIL PROTECTED] (Niels Möller) writes:
> Does anybody have any idea how often this case occurs with typical
> activities like compilation?
What's the point of the question: to decide if we can ignore the
issue, or to decide if the solution has to be terribly efficient?
> With the current code
Thanks for the explanation. I'm trying to understand what consequences
for performance can be expected.
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> There are cases (as noted before) where the following sequence arises:
>
> write block A
> write block B
> write block A again
>
> and wher
On Wed, Mar 27, 2002 at 03:33:03PM -0500, Marcus Brinkmann wrote:
> On Thu, Mar 28, 2002 at 10:12:12AM -0700, Jon Arney wrote:
> > Here's a start at some performance statistics. I suggest that
> > if anyone else is interested in characterizing the system that
> > they begin with downloading bonni
> It looks like there is less than 1% of cpu time used by tar. And about 3% of
> cpu time spent in kernel code.
I don't know how you got these results but what I observed under Linux is
about 60% of CPU time spent in kernel code (and almost nothing is user land).
The problem with the Hurd is that
On Tue, Mar 26, 2002 at 12:55:19PM -0800, Thomas Bushnell, BSG wrote:
> [EMAIL PROTECTED] (Niels Möller) writes:
>
> > Perhaps idling, waiting for disk i/o requests to complete?
>
> Do a big tar extraction on Linux and note that your tar process soaks
> up plenty of CPU time.
I tried it, but i
On Thu, Mar 28, 2002 at 10:12:12AM -0700, Jon Arney wrote:
> Here's a start at some performance statistics. I suggest that
> if anyone else is interested in characterizing the system that
> they begin with downloading bonnie:
>
> http://www.textuality.com/bonnie/download.html
>
> Run it under t
On Wed, Mar 27, 2002 at 03:26:46PM +0100, Jeroen Dekkers wrote:
> I recall seeing "nice() failed" messages the last time I tried X under
> the Hurd, I think that's the reason for this. Try setting the X
> priority to the same value as all other processes imder GNU/Linux and
> start doing unpacking
Hi,
At the risk of being too abrasive, I'd like to weigh in on the
issues of performance characterization I saw during the course
of this thread and hope to clear up a potential misunderstanding.
I begin by examining an argument presented on CPU utilization and
move on to provide what I believe i
On Wed, Mar 27, 2002 at 03:11:25PM +0100, Ludovic Court?s wrote:
> > But anyway, for a performance comparison between Hurd and Linux to be
> > meaningful, one would have to do it on the same or at least pretty
> > similar hardware. I just wanted to point out that I wouldn't expect
> > all kinds of
> But anyway, for a performance comparison between Hurd and Linux to be
> meaningful, one would have to do it on the same or at least pretty
> similar hardware. I just wanted to point out that I wouldn't expect
> all kinds of heavy disk mangling to necessarily imply heavy cpu
> activity.
Well, th
> This is on my good old Sparc station 4, a reasonably modern (low-end,
> less than two years old) IBM scsi disk, and linux-2.2.19. I'd expect
> more idle cycles on a modern machine and decent disk hardware, but I
> don't have any around.
You need to consider the correlation between the cpu speed
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> So on the Hurd, you had 30%, and on Linux, you have 60%?
Sorry, it seems I was too careless when reading Ludovic Courtès'
message, I read "most of the cpu time" but missed the parenthesis
saying "30 %".
But anyway, for a performance compariso
[EMAIL PROTECTED] (Niels Möller) writes:
> The numbers depend a lot on the actual hardware, and the relative
> speed of the cpu and disks, I think. I just tried extracting
> gcc-3.0.4.tar (note, no .gz, unzipping would soak up most of the idle
> time). top reported that the tar process consumed a
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> [EMAIL PROTECTED] (Niels Möller) writes:
>
> > Perhaps idling, waiting for disk i/o requests to complete?
>
> Do a big tar extraction on Linux and note that your tar process soaks
> up plenty of CPU time.
The numbers depend a lot on the actua
[EMAIL PROTECTED] (Niels Möller) writes:
> Perhaps idling, waiting for disk i/o requests to complete?
Do a big tar extraction on Linux and note that your tar process soaks
up plenty of CPU time.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Ludovic Courtès <[EMAIL PROTECTED]> writes:
>
> > This kind of observation is quite normal I guess, due to the extensive use of
> > RPCs and so on, but are there still some optimizations that could be
> > implemented in order to reduce CPU consu
[EMAIL PROTECTED] (Niels Möller) writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > I have a more concrete idea about how to change diskfs into an
> > "ordered writes" instead of a "synchronous writes" model. If someone
> > prods me, I can explain it.
>
> Please do.
Suppose disk
Ludovic Courtès <[EMAIL PROTECTED]> writes:
> This kind of observation is quite normal I guess, due to the extensive use of
> RPCs and so on, but are there still some optimizations that could be
> implemented in order to reduce CPU consumption?
Where do you think the processor should be spending
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I have a more concrete idea about how to change diskfs into an
> "ordered writes" instead of a "synchronous writes" model. If someone
> prods me, I can explain it.
Please do.
Regards,
/Niels
___
Bug
[EMAIL PROTECTED] (Niels Möller) writes:
> How hard would it be to create a new store type that basically
> implements only a write-cache: It would have store_write put the
> modified block into a queue, from which blocks are written to the
> underlying store later by a separate syncing thread. s
[EMAIL PROTECTED] (Niels Möller) writes:
> Is it not good enough to maintain the order of the writes, updating
> diskblocks in the same order as the corresponding write by the client?
Yes, that's enough. But you cannot skip any writes.
> One problem is that if the filesystem modifies block A,
On Mon, Mar 25, 2002 at 09:53:41PM +0100, Niels Möller wrote:
> One problem is that if the filesystem modifies block A, then block B,
> and then block A again, then you may need to keep this ordering, and
> not merge it as one write to A and one to B. Is the touch-rm-loop of
> this kind? Then I gu
On Tue, Mar 26, 2002 at 11:04:14AM -0700, Jon Arney wrote:
> I understand the goals of having disk syncrhonization performed
> in the proper order to avoid disk inconsistencies. I also,
> however, agree with Adam that something less than "optimal"
> might be better than nothing at all.
We have s
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Well, if this is possible we could just avoid syncing the blocks back to the
> store in the filesystem in the first place. Thomas' point is exactly that
> to make the expected guarantees you can not cache the writes in any
> simplistic fashion: You
On Mon, Mar 25, 2002 at 08:47:44PM +0100, Niels Möller wrote:
> How hard would it be to create a new store type that basically
> implements only a write-cache: It would have store_write put the
> modified block into a queue, from which blocks are written to the
> underlying store later by a separa
Jon Arney <[EMAIL PROTECTED]> writes:
> For instance, a simple LRU cache algorithm implemented in
> 'libstore' might provide a large performance advantage with
> the caveat that it might occasionally lead to disk inconsistencies.
The important thing for this problem is to cache writes, I think.
I noticed this activity as well quite a while back. It's not
limited to 'rm'. I also wrote a similar test script with 'mv'
and even a 'hello-world' with 'rename' to continuously rename
a file from 'foo.0' to foo.fff and the drive light just went
_crazy_. As you observed, the same sort of th
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> It must guarantee that the directory is updated to drop the link
> *before* the inode refcnt is decremented and the inode possibly
> cleared.
>
> So it synchronously writes the directory, and then lets the inode get
> cleared on the next regular
Atle <[EMAIL PROTECTED]> writes:
> When running a telnet session from my Linux PC to a BSD box, I see the
> disk lamp go on, and I hear the disk go 'chack' each time I press a key
> on the keyboard!
It's updating the mtime on the terminal node.
___
B
Marcus Brinkmann wrote:
>
> On Mon, Mar 25, 2002 at 04:18:05PM +0100, Philip Dodd wrote:
> > One of the things I first noticed when running the Hurd (particularly
> > because it was running with an old and very noisy HD) was the incredible
> > amount of disk activity compared with exactly the sam
On Mon, Mar 25, 2002 at 10:07:25AM -0500, Marcus Brinkmann wrote:
> Hi,
>
> I just found out that
>
> while touch /tmp/foo; do rm /tmp/foo; done
>
> causes a lot of disk activity. Further tests showed that the disk is
> activated for each rm. Is this a hard requirement? In Linux, the loop
>
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> causes a lot of disk activity. Further tests showed that the disk is
> activated for each rm. Is this a hard requirement? In Linux, the loop
> above does not cause any disk activity (except at the beginning and
> maybe at the end), it seems to be
On Mon, Mar 25, 2002 at 10:23:25AM -0500, Marcus Brinkmann wrote:
> On Mon, Mar 25, 2002 at 04:18:05PM +0100, Philip Dodd wrote:
> > One of the things I first noticed when running the Hurd (particularly
> > because it was running with an old and very noisy HD) was the incredible
> > amount of disk
On Mon, Mar 25, 2002 at 04:18:05PM +0100, Philip Dodd wrote:
> One of the things I first noticed when running the Hurd (particularly
> because it was running with an old and very noisy HD) was the incredible
> amount of disk activity compared with exactly the same box running any other
> OS. This
One of the things I first noticed when running the Hurd (particularly
because it was running with an old and very noisy HD) was the incredible
amount of disk activity compared with exactly the same box running any other
OS. This is of course an entirely subjective expression of opinion, and
shoul
Hi,
I just found out that
while touch /tmp/foo; do rm /tmp/foo; done
causes a lot of disk activity. Further tests showed that the disk is
activated for each rm. Is this a hard requirement? In Linux, the loop
above does not cause any disk activity (except at the beginning and
maybe at the end
52 matches
Mail list logo
