So in an attempt to summarise the situation, what are the advantages of RSDL
over mainline.
Fairness
why do you think fairness is good, especially always good?
Starvation free
even starvation is sometimes a good thing - there's a place for processes
that only use the CPU if it is otherwise
some allocations to fail.
this is often much nicer than the default random OOM slaughter.
(you probably also need to adjust vm.overcommit_ratio with
some knowlege of your MemTotal and SwapTotal.)
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
0 MB/s range, so this is not
surprising. readahead is certainly one, but there are also magic numbers
in MD as well, not to mention PCI latency, scsi driver tuning, probably
even /proc/sys/vm settings.
I've got some 4x2.6G opteron servers (same board, 32G PC3200), but alas,
end-users have found
> > if CKRM is just extensions, I think it should be an external patch.
> > if it provides a path towards unifying the many disparate RM mechanisms
> > already in the kernel, great!
>
> OK, so if it provides a path towards unifying these, what should happen
> to the old interfaces when they confli
rocess nice
> is the class is less transient than the process since its lifetime is
> determined solely by the system administrator.
but the Linux RM needs to subsume traditional Unix process groups,
and inherited nice/schd class, and even CAP_ stuff. I think CKRM
could start to do this, since
; can grow into a pain under virtualization. But I still maintain that
> both have their place.
CKRM may have its place in an externally-maintained patch ;)
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> of the various environments. I don't think you are one of those end
> users, though. I don't think I'm required to make everyone happy all
> the time. ;)
the issue is whether CKRM (in it's real form, not this thin edge)
will noticably hurt Linux's fast-path.
-
To unsubscribe from this list:
> > > yes, that's the crux. CKRM is all about resolving conflicting resource
> > > demands in a multi-user, multi-server, multi-purpose machine. this is a
> > > huge undertaking, and I'd argue that it's completely inappropriate for
> > > *most* servers. that is, computers are generally so dam
sn't meet CKRM's goal of flexible, wide-spread resource
partitioning within a large, shared machine.
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> I've written a small test program which enables periodic RTC interrupts
> at 8192 Hz and then goes into a loop reading /dev/rtc and collecting
> timing statistics (using the rdtscl macro).
straightforward test, used for many years in the linux community
(I claim to have been the first to publi
> > Would it be possible to maintain a dirty-rate count
> > for the dirty buffers?
> >
> > For example, we it is possible to figure an approximate
> > disk subsystem speed from most of the given information.
>
> Disk speed is difficult. I may enable and disable swap on any number of
...
> You m
> reads the RTC device. The patched RTC driver can then
> measure the elapsed time between the interrupt and the
> read from userspace. Voila: latency.
interesting, but I'm not sure there's much advantage over
doing it entirely in user-space with the normal /dev/rtc:
http://brain.mcmas
> XMM is heavily modified XMEM utility that shows graphically size of
> different Linux page lists: active, inactive_dirty, inactive_clean,
> code, free and swap usage. It is better suited for the monitoring of
> Linux 2.4 MM implementation than original (XMEM) utility.
>
> Find it here: http://
> while observing lots of different workloads (all I/O bound). Finally,
well, not all loads are IO-bound in the sense you're looking at.
in particular, the test I usually run (make -j2 with mem=48m)
is actually hurt by this patch. but you're right, this change
does improve streaming IO.
> We'r
> > contrary to the implication here, I don't believe there is any *general*
> > problem with Linux/VIA/AMD stability. there are well-known issues
...
> VIA hardware is not suitable for anything until we _know_ the
> truth about what is wrong. VIA is hiding something big.
this is INCORRECT: we k
> This report is probably not very helpful, but it may be useful for those who
> planned to purchase AMD / VIA solution for a server.
contrary to the implication here, I don't believe there is any *general*
problem with Linux/VIA/AMD stability. there are well-known issues
with specific items (VI
> I think I've found a serious bug in AMD Athlon page_alloc.c routines in
there's nothing athlon-specific there.
> correct on the DFI AK75-EC motherboard, if I set the CPU kernel type to 586
> everything is 100%, if I use "Athlon" kernel type I get:
> kernel BUG at page_alloc.c:73
when you sele
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
read the fine faq.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www
On Fri, 11 May 2001, Jeff Garzik wrote:
...
> Subsystems are often maintained outside the Linus tree, with code
> getting pushed (hopefully regularly) to Linus. For such scenarios, it
"maintained" *means* that the fixes/development get fed to Linus.
afaikt, the LVM/ISDN/etc situations were probl
> > also -- isn't it kind of wrong for arp to respond with addresses from
> > other interfaces?
>
> Usually it makes sense, because it increases your chances of successfull
> communication. IP addresses are owned by the complete host on Linux, not by
> different interfaces.
this is one of those
On Fri, 4 May 2001, Seth Goldberg wrote:
> Hi,
>
> Before I go any further with this investigation, I'd like to get an
> idea
> of how much of a performance improvement the K7 fast_page_copy will give
> me.
> Can someone suggest the best benchmark to test the speed of this
> routine?
Arjan va
> > this has nothing to do with the very specific disk corruption
> > being discussed (which has to do with the ide controller, according
> > to the most recent rumors.).
>
> Actually, I think there are 2 problems that have been discussed -- the
> disk corruption and a general instability resul
he most recent rumors.).
> The other thing i was gunna try is to dump my chipset registers using
> WPCREDIT and WPCRSET and compare them with other people on this list
why resort to silly windows tools, when lspci under Linux does it for you?
regards, mark hahn.
-
To unsubscribe from this
> + * Make sure the child gets the SCHED_YIELD flag cleared, even if
> + * it inherited it, to avoid deadlocks.
can anyone think of a reason that SCHED_YIELD *should* be inherited?
I think it's just oversight that fork doesn't clear it.
-
To unsubscribe from this list: send the line "u
am, and keeps it active (printing out a
handy measure of how long it took to touch its pages...)
regards, mark hahn.
#include
#include
#include
#include
#include
volatile unsigned sink;
double second() {
struct timeval tv;
gettimeofday(&tv,0);
return tv.
e types and tags of a datum (or hierarchy), so that on subsequent
queries, they'd now how to handle binary data.
if only one piece of code handled the rendering of /proc stuff,
it could do more, without burdoning all the disparate /proc producers.
regards, mark hahn.
-
To unsubscribe from t
Dennis is like a pie in the face: messy, unexpected, but trivial.
On Wed, 18 Apr 2001, Dennis wrote:
> Does 2.4 have something similar to spl levels or does it still require the
> ridiculous MS-DOSish spin-locks to protect every bit of code?
-
To unsubscribe from this list: send the line "un
> > isn't this a solution in search of a problem?
> > does it make sense to redesign parts of the kernel for the sole
> > purpose of making a completely unrealistic benchmark run faster?
>
> Irrespective of the usefulness of the "chat" benchmark, it seems
> that there is a problem of scalability
> The improvement in performance while runnig "chat" benchmark
> (from http://lbs.sourceforge.net/) is about 30% in average throughput.
isn't this a solution in search of a problem?
does it make sense to redesign parts of the kernel for the sole
purpose of making a completely unrealistic benchma
the stack;
they wouldn't be happy ;)
a simple workaround would be to turn TASK_UNMAPPED_AREA into a variable,
either system-wide or thread-specific (like ia64 already has!). that's
compatible with the improved vmas-down approach, too.
regards, mark hahn.
-
To unsubscribe from this li
> can get at most 2GB. Newer glibc's allow you to tune the definition
> of "small" via an environment variable.
eventually, perhaps libc will be smart enough to create
more arenas in mmaped space once sbrk fails. note, though,
that you *CAN* actually malloc a lot more than 1G: you just
have to
> 2. A Fileserver with an ABIT Hotrod 66 (htp366) controller will crash within
> 5-60 minutes after boot with a 2.4.x kernel. 2.2.x works fine. No other
no problem with ext2 on hpt366 here.
> Gnu C 2.95.3
hmm.
-
To unsubscribe from this list: send the line "unsubscribe linux-k
> > > > handle the situation with 2 different CPUs (AMP = Assymmetric
> > > > multiprocessing ;-) correctly.
> > >
> > > "correctly". Intel doesn't support this (mis)configuration:
> > > especially with different steppings, not to mention models.
>
> I wouldn't call it misconfiguration, just be
ernel should LOUDLY WARN ABOUT this stuff on boot.
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
>Device BootStart EndBlocks Id System
> /dev/hda1 * 1 932 7486258+ b Win95 FAT32
> /dev/hda2 933 3737 22531162+ 5 Extended
> /dev/hda5 933 935 24066 83 Linux
> /dev/hda6 936 952136521 82 Lin
s hdparm output
for a disk of the same rpm and density as the DTLA's:
Timing buffer-cache reads: 128 MB in 1.07 seconds =119.63 MB/sec
Timing buffered disk reads: 64 MB in 2.02 seconds = 31.68 MB/sec
(maxtor dm+45, hpt366 controller)
regards, mark hahn.
-
To unsubscribe from this l
> itself is a bad thing, particularly given the amount of CPU overhead that
> IDE drives demand while attached to the controller (orders of magnitude
> higher than a good SCSI controller) - the more overhead we can hand off to
I know this is just a troll by a scsi-believer, but I'm biting anyway.
> > > > > Well, somethig has broken in ac8, because I lost my PS/2 mouse and
> > > > me too .
> No luck.
it seems to be the mdelay(2) added to pc_keyb.c in -ac6.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
> the cable length in mind. Anybody out there know if there's a max cable
> length for the ATA/100 spec??
18", like *all* ide/ata cables.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.
> do know I get the feeling they don't care to support Linux in any way
> shape or form. Feels like a pawn off job.
afaik, there's no hardware raid support in the chip - it's just
another dual-channel controller, with some raid0 (perhaps raid1)
software in bios. I think Andre has said that he h
> > Would it be possible to grow and shring that buffer on demand?
> > Let's say we have a default size and let it grow to a maximum
> > value. After some timeout, buffer size can be shrinked to
> > default value if it's enough at that moment. Or something
> > similar.
>
> And when you can't allo
>From what I gather this chipset on 2.4.x is only stable if you cripple just about
>everything that makes
> it worth having (udma, 2nd ide channel etc etc) ?does it even work when all
>that's done now or is
> it fully functional?
it seems to be fully functional for some or most people,
wi
> Kernel 2.4.1-pre11 and pre12 are both massively slower than 2.4.0 on the
> same machine, compiled with the same options. The machine is a Athlon
> 900 on a KT133 chipset. The slowdown is noticealbe in all areas...
this is known: Linus decreed that, since two people reported
disk corruption o
> I am not a guru, but AOpen AK73PRO which uses VIA KT133 does not
> show any of these symptoms that you describe (I cannot be sure
> about #3 since I run ntp). You may want to make your hardware
my ga-7zm shows none of them either (I also run ntp, and the board
has a perfectly normal drift his
> #ifdef SLOW_IO_BY_JUMPING
> #define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
> #else
> -#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
> +#define __SLOW_DOWN_IO "\noutb %%al,$0x19"
this is nutty: why can't udelay be used here? empirical measurements
in the thread show the delay is O(2us).
-
T
> >microseconds/yield
> > # threads 2.2.16-22 2.42.4-multi-queue
> > - ---
> > 16 18.7404.603 1.455
>
> I remeber the O(1) scheduler from Davide Libenzi was
> This way we are 100% consistent and we don't lose the "cpu_has" information.
but /dev/cpu/*/{msr|cpuid} are "cpu has".
-
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/
ge is a *warning* - an inter-apic message
was corrupted, and automatically retried.
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/
is cause file system corruption in any way?
abosolutely not. udma checksums each transfer. when checksums don't match,
the *hardware* retries the transfer (and incidentally reports the event,
which Linux obligingly passes on to you.)
regards, mark hahn.
-
To unsubscribe from this list:
> since Mark posted his views to the list, I figured I could safely post the
> conversation I've been having with him in email
which is universally considered rude, if not illegal.
in any case, please don't respond to this thread, which is quite off-topic.
-
To unsubscribe from this list: sen
> I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to
...
> afraid that this may partialy criple 2.2 driver development.
egads! how can there be "development" on a *stable* kernel line?
maybe this is the time to reconsider terminology/policy:
does "stable" mean "bugfixes
articularly nice
_notification_ mechanism...
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/
> > - 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 unsubsc
> 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 'kap
> 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"
> 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 versio
> > 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
> 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 vi
wing is wrong:
if (can_get_io_locks && !launder_loop && 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/
> 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 no
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 "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 perfo
> 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-kerne
> 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 s
> 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
> 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 lin
k the tags 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 unsub
> > 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
sw
bout unoptimized 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
72 matches
Mail list logo
