>For x86 Im beginning to wonder if the FPU save/restore is at least one of
>the L1 cache munchers. If so the effect should be visible on 2.2 x86 but
HINT definitely uses the FPU. But since HINT runs in loop I don't expect
frequent reschedule and so I don't expect many save/restore of the FPU
(supposing that the current FPU save/restore code is doing the right
thing).
>not as much on 2.0 x86. That would be worth knowing
>From the original graph it seems that 2.2.7 and 2.0.36 perform exactly the
same and this make sense to me, see below.
HINT stress only the memory (no IO, no access to disk, nothing). So
there's a little to do in order to go faster.
Really HINT stress the page allocation code in the first run of the code
but I think it's not a big issue (it should also automatically reject slow
runs that may be run slower..). Anyway you can apply this my patch and
rerun HINT on the same machine first in FreeBSD and then in Linux to make
sure that the difference isn't in the anonymous page allocation:
--- /home/andrea/devel/HINT/serial/unix.orig/hint.c Sun May 31 22:34:52 1998
+++ hint.c Tue May 4 18:50:31 1999
@@ -309,6 +309,13 @@
*eflag = NOMEM;
return (-NOMEM);
}
+
+ /* This hack will avoid us to benchmark also the page allocation time while
+ * running with amount of memory that fits in RAM. -Andrea
+ */
+ bzero(rect, (MSIZE)(memry * sizeof(RECT)));
+ bzero(errs, (MSIZE)(memry * sizeof(DSIZE) * 2));
+ bzero(ixes, (MSIZE)(memry * sizeof(ISIZE) * 2));
for (i = 0; i < NTRIAL; i++)
{
The other thing that does HINT is to call gettimeofday every some second
(after and before every run), but it's not an issue.
So the last thing that make me to think is the timer irq handler that
maybe is flushing the L1 cache too much (maybe the freebsd one is so
lighter?). I think that the timer irq it's the only bit of code that may
harm HINT performances compared with freebsd.
So could you try to apply this really unsafe patch ;) and then rerun HINT?
Index: linux/include/asm-i386/param.h
===================================================================
RCS file: /var/cvs/linux/include/asm-i386/param.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 param.h
--- linux/include/asm-i386/param.h 1999/01/18 01:27:15 1.1.1.1
+++ linux/include/asm-i386/param.h 1999/05/04 16:56:21
@@ -2,7 +2,7 @@
#define _ASMi386_PARAM_H
#ifndef HZ
-#define HZ 100
+#define HZ 10
#endif
#define EXEC_PAGESIZE 4096
If you are lucky ;) gettimeofday should continue to work..., if so you
should be able to run HINT also with the patch above applyed (ah and make
sure to do a `make clean' before recompile, just to be more sure that
there won't be piece of asm that think that HZ is still 100). The patch in
turn this will also decrease the scheduling frequency of the task (but I
don't think that was the issue since if it doesn't swapout the rate of
the scheduling should be really lowww).
Ah and make _sure_ to not have other application running while running
HINT. You can kill also `update`.
Another thing you may try is to compile with gcc -pg and to use gprof to
get the profiler results (I suppose also bsd can run gcc -pg?). Maybe we
are spending more time in some particular function (I don't think so
though). If you'll do that you can send the gprof results back to me.
Thanks.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/