- metrics -- L1 cacheline size is the important one: you align array
...
Anyone can give me some pointers on how this is done runtime ? (name of
the .c file is fine).
kernel/sched.c:aligned_data. as mentioned elsewhere,
the correct alignment is not necessarily L1 linesize.
-
To
> Technical merits and voter intent aside, this behavior is misleading and
> inconsistent with previous kernels. Tools like top or a CPU dock applet show
the goal of kernel revision is *not* to remain consistent with old stuff.
> a constantly loaded CPU. Hacking them to deduct the load from
Technical merits and voter intent aside, this behavior is misleading and
inconsistent with previous kernels. Tools like top or a CPU dock applet show
the goal of kernel revision is *not* to remain consistent with old stuff.
a constantly loaded CPU. Hacking them to deduct the load from
> The following patch moves the page_table_lock in mm/* to cover the
> modification of mm->rss in 240-test12-pre7. It was inspired by a
can't we just change rss to count pages?
or are we worried about rss's over ~16 TB?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
The following patch moves the page_table_lock in mm/* to cover the
modification of mm-rss in 240-test12-pre7. It was inspired by a
can't we just change rss to count pages?
or are we worried about rss's over ~16 TB?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> Actually, there is some benefit in leaving the LINUX_VERSION_CODE checks
> there... If someone wants to back-port the driver to 2.2, this makes it
> much easier. Also, some people like to maintain a single driver for all
> of the kernel versions, so they don't have to bugfix each driver
Actually, there is some benefit in leaving the LINUX_VERSION_CODE checks
there... If someone wants to back-port the driver to 2.2, this makes it
much easier. Also, some people like to maintain a single driver for all
of the kernel versions, so they don't have to bugfix each driver version.
> > Multics??? [..] way too many persons on this list who know the history of
> > Unix to try this BS.
>
> So, you're saying their nine goals were bullshit? Multics had a lot of
> problems. But it did a lot of ground-breaking. Perhaps you should reply
> to the nine goals, or the general topic
Multics??? [..] way too many persons on this list who know the history of
Unix to try this BS.
So, you're saying their nine goals were bullshit? Multics had a lot of
problems. But it did a lot of ground-breaking. Perhaps you should reply
to the nine goals, or the general topic of
> > 8cpu2193| 58 22114 946099 52 39
> ^
>
> This is pretty insane and is definately a bug which should
> be fixed. I'll search the source for "suspicious" changes
> and try to come up with a patch you can
8cpu2193| 58 22114 946099 52 39
^
This is pretty insane and is definately a bug which should
be fixed. I'll search the source for "suspicious" changes
and try to come up with a patch you can test.
> APIC error on CPU1 00(02) or 02(02) or 00(08) or 00(04)
BP6 bugs, not linux's, and especially not ide's fault. you have to
do the usual BP6 voodoo: bios update, extra fans, big PS, higher voltage.
> The machine has four IDE ports on the motherboard, two are UDMA33,
> two are UDMA66
APIC error on CPU1 00(02) or 02(02) or 00(08) or 00(04)
BP6 bugs, not linux's, and especially not ide's fault. you have to
do the usual BP6 voodoo: bios update, extra fans, big PS, higher voltage.
The machine has four IDE ports on the motherboard, two are UDMA33,
two are UDMA66 via
;& free_shortage()) {
(vmscan.c:page_launder) should be "free_shortage > 0". there are
about a dozen other similar places, for which I'll shortly post a patch.
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
ll shortly post a patch.
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
> This is something that has been bugging me for a while. I notice
> on my system that during disk write we do much context switching,
> but not during disk read. Why is that?
bdflush is broken in current kernels. I posted to linux-mm about this,
but Rik et al haven't shown any interest. I
This is something that has been bugging me for a while. I notice
on my system that during disk write we do much context switching,
but not during disk read. Why is that?
bdflush is broken in current kernels. I posted to linux-mm about this,
but Rik et al haven't shown any interest. I
George France, and I sincerely
apologize to George France for any misunderstandings I may have caused.
sincerely, Mark Hahn.
--
operator may differ from spokesperson. [EMAIL PROTECTED]
http://brain.mcmaster.ca/~hahn
-- Forwarded
George France, and I sincerely
apologize to George France for any misunderstandings I may have caused.
sincerely, Mark Hahn.
--
operator may differ from spokesperson. [EMAIL PROTECTED]
http://brain.mcmaster.ca/~hahn
-- Forwarded
> the original process on a system fast enough to wrap the
> pid counter in < 1 sec?
on a recent, entry-level system (duron/600, 128M PC133)
I see ~13000 fork/child-exit/wait cycles per second.
clone is even worse (better): ~42K/second!
-
To unsubscribe from this list: send the line
the original process on a system fast enough to wrap the
pid counter in 1 sec?
on a recent, entry-level system (duron/600, 128M PC133)
I see ~13000 fork/child-exit/wait cycles per second.
clone is even worse (better): ~42K/second!
-
To unsubscribe from this list: send the line "unsubscribe
> kernel proper and working. If it *IS* ready now, what sort of
> Athlon hardware is recommended for a developmental machine?
I HIGHLY recommend duron/thunderbird, KT133, PC133, UDMA machines;
they work very well with modern (2.4) kernels. K6-2 machines are
not anywhere close to the same
kernel proper and working. If it *IS* ready now, what sort of
Athlon hardware is recommended for a developmental machine?
I HIGHLY recommend duron/thunderbird, KT133, PC133, UDMA machines;
they work very well with modern (2.4) kernels. K6-2 machines are
not anywhere close to the same
> Linux 2.2.17 only allows 255 processes at any one time. Is this a
...
> Can't fork any more after 255 processes
ulimit -u
getting back OT, current entry-level PCs (duron/600) can easily
do 7000 fork/wait pairs per second.
-
To unsubscribe from this list: send the line "unsubscribe
Linux 2.2.17 only allows 255 processes at any one time. Is this a
...
Can't fork any more after 255 processes
ulimit -u
getting back OT, current entry-level PCs (duron/600) can easily
do 7000 fork/wait pairs per second.
-
To unsubscribe from this list: send the line "unsubscribe
> him, but he has cut off all commutations. So starting tomorrow, we will be
> submitting patches directly to the kernel mailing list, since Russell will
uh, this will be unpleasantly familiar to anyone who
was reading the linux-usb mailing list in Dec 99,
when George said, roughly "you are all
him, but he has cut off all commutations. So starting tomorrow, we will be
submitting patches directly to the kernel mailing list, since Russell will
uh, this will be unpleasantly familiar to anyone who
was reading the linux-usb mailing list in Dec 99,
when George said, roughly "you are all so
> The problem is large numbers of threads in 2.4.0-test8 can result in a
> hard crash of the entire kernel. This can be done as a non-root user.
this appears to be reproducable (128M duron, haven't tried intel UP/SMP):
// code derived from a clone demo in lmbench.
#include
#include
#include
The problem is large numbers of threads in 2.4.0-test8 can result in a
hard crash of the entire kernel. This can be done as a non-root user.
this appears to be reproducable (128M duron, haven't tried intel UP/SMP):
// code derived from a clone demo in lmbench.
#include signal.h
#include
> your email inundation by one. Er, why's the list setup without
> a reply-to the list?)
lists that add "reply-to: list" degenerate to chat rooms.
so this is social-engineering, just like the lack of builtin kernel debugger.
-
To unsubscribe from this list: send the line "unsubscribe
your email inundation by one. Er, why's the list setup without
a reply-to the list?)
lists that add "reply-to: list" degenerate to chat rooms.
so this is social-engineering, just like the lack of builtin kernel debugger.
-
To unsubscribe from this list: send the line "unsubscribe
of queued commands, including those via ide_ioctl.
but ensuring tag sanity is very different from filtering.
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
> have trouble with the readings bonnie gives me.
um, that's because you used too-small a file. try it with -s
at least 3x the size of ram.
so far, reports are fairly consistent that Rik's patch cause a minor hit
in sustained disk IO, and some real benefit on low-memory machines.
-
To
have trouble with the readings bonnie gives me.
um, that's because you used too-small a file. try it with -s
at least 3x the size of ram.
so far, reports are fairly consistent that Rik's patch cause a minor hit
in sustained disk IO, and some real benefit on low-memory machines.
-
To
> > Any of you tried copying a 2G file in the same (ext2)
> > filesystem? It starts swapping like mad and generally behaves
> > indecently, despite the huge 1024M of RAM it has.
>
> http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2
this patch works very nicely. it's still a little timid at
Any of you tried copying a 2G file in the same (ext2)
filesystem? It starts swapping like mad and generally behaves
indecently, despite the huge 1024M of RAM it has.
http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2
this patch works very nicely. it's still a little timid at
swapping
noptimized code. and to spuriously inflate
the memory traffic in this femto-benchmark. measured sanely, optimized
with 2.95.2 on a celeron/450, long long costs ~2-3x as much.
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
. and to spuriously inflate
the memory traffic in this femto-benchmark. measured sanely, optimized
with 2.95.2 on a celeron/450, long long costs ~2-3x as much.
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
P
101 - 138 of 138 matches
Mail list logo
