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
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
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-kernel&
.
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-kernel in
the body of a message to [EMAIL
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 out about them. not to men
(same board, 32G PC3200), but alas,
end-users have found out about them. not to mention that they only have
3x160G SATA disks...
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
> > 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
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 conflict with
lass 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 classes are very g
nder 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/
;)
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/
to subsume traditional Unix process groups,
and inherited nice/schd class, and even CAP_ stuff. I think CKRM
could start to do this, since classes are very general.
but merely adding a new, incompatible feature is just Not A Good Idea.
regards, mark hahn.
-
To unsubscribe from this list: send
> 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
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 damn cheap
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:
e-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/
, 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
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 publish
> > 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
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 may be able
> 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:
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:
> 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:
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:
> > 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
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 know
> 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
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 (VIA
> 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
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 select
> 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
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
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
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 problems
> > 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
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 things
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
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 van de
> > 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
st 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 list
> + * 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
+ * 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
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 list: send the line
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 resulting in
ive (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(,0);
return tv.tv_sec + 1e-6 * tv.tv_us
r 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 this list: send the line "unsub
to touch its pages...)
regards, mark hahn.
#include unistd.h
#include stdlib.h
#include stdio.h
#include sys/time.h
#include sys/mman.h
volatile unsigned sink;
double second() {
struct timeval tv;
gettimeofday(tv,0);
return tv.tv_sec + 1e-6 * tv.tv_usec;
}
int
main
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
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
> > 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
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 as long
> 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
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
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 list: send the line "unsubscribe
> 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
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
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 list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m
> 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
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
> > > > 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
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 because it's a bit
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/
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
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 Linux
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 list: send the line &
B 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 list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
> 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
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
Well, somethig has broken in ac8, because I lost my PS/2 mouse and
me too /aol.
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 info
> 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
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
> 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
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
> > 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
>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,
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 allocate memory
> 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
> 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
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
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 on
> #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).
-
#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).
-
To
> >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
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 beating
> 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/
s 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/
-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/
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/
ile 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: send th
y 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: send the line "unsubscribe linux-kernel&qu
> 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:
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: send
> 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
tification_ 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/
, 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
1 - 100 of 138 matches
Mail list logo
