jmerkey wrote:
It might be helpful for someone to look at these sections of code I
had to patch in 2.6.9.
I discovered a case where the kernel scheduler will pass NULL for the
array argument
when I started hitting the extreme upper range > 200MB/S combined disk
and lan
throughput. This was
jmerkey wrote:
It might be helpful for someone to look at these sections of code I
had to patch in 2.6.9.
I discovered a case where the kernel scheduler will pass NULL for the
array argument
when I started hitting the extreme upper range 200MB/S combined disk
and lan
throughput. This was
Denis Vlasenko wrote:
This is what I would expect if run on an otherwise idle machine.
sched_yield just puts you at the back of the line for runnable
processes, it doesn't magically cause you to go to sleep somehow.
When a kernel build is occurring??? Plus `top` itself It damn
well
Denis Vlasenko wrote:
This is what I would expect if run on an otherwise idle machine.
sched_yield just puts you at the back of the line for runnable
processes, it doesn't magically cause you to go to sleep somehow.
When a kernel build is occurring??? Plus `top` itself It damn
well
Avi Kivity wrote:
parallelized initscripts will probably defeat this, though.
put all run-once-but-never-run-again scripts into initrd / initramfs?
boot into a suspend-to-disk image?
i still see the real solution at least for "desktop" machines is to
minimize the sheer amount of stuff
Avi Kivity wrote:
parallelized initscripts will probably defeat this, though.
put all run-once-but-never-run-again scripts into initrd / initramfs?
evil grin
boot into a suspend-to-disk image?
i still see the real solution at least for desktop machines is to
minimize the sheer amount of
At 02:34 AM 1/04/2005, linux-os wrote:
For those interested, some file-system tests and a test-tools
are attached.
in high-performance-I/O-testing i perform regularly, i notice no slowdown
in 2.6 compared to 2.4.
looking at your test-tools, i would hardly call your workload anywhere near
At 02:34 AM 1/04/2005, linux-os wrote:
For those interested, some file-system tests and a test-tools
are attached.
in high-performance-I/O-testing i perform regularly, i notice no slowdown
in 2.6 compared to 2.4.
looking at your test-tools, i would hardly call your workload anywhere near
At 07:43 AM 16/03/2005, comsatcat wrote:
Unfortunantly all the beta drivers seem to have issues working with
mcdata switches. I've tried about 10 different versions available from
qlogic's ftp and all of them give trace messages and "scheduling while
atomic" messages when detecting luns that are
At 07:43 AM 16/03/2005, comsatcat wrote:
Unfortunantly all the beta drivers seem to have issues working with
mcdata switches. I've tried about 10 different versions available from
qlogic's ftp and all of them give trace messages and scheduling while
atomic messages when detecting luns that are
At 08:32 PM 4/02/2005, Andrew Morton wrote:
Something funny is happening here - it looks like there's plenty of CPU
capacity left over.
[..]
Could you monitor the CPU load during the various tests? If the `dd'
workload isn't pegging the CPU then it could be that there's something
wrong with the
At 08:32 PM 4/02/2005, Andrew Morton wrote:
Something funny is happening here - it looks like there's plenty of CPU
capacity left over.
[..]
Could you monitor the CPU load during the various tests? If the `dd'
workload isn't pegging the CPU then it could be that there's something
wrong with the
At 01:34 PM 2/02/2005, Timothy Miller wrote:
I've mentioned this problem before. It seemed to go away around the
2.6.8 timeframe, but when I started using 2.6.9, it came back. I'm
using 2.6.10, and it's still happening.
almost identical system here, other than i'm using an ASUS A7V600
At 01:34 PM 2/02/2005, Timothy Miller wrote:
I've mentioned this problem before. It seemed to go away around the
2.6.8 timeframe, but when I started using 2.6.9, it came back. I'm
using 2.6.10, and it's still happening.
almost identical system here, other than i'm using an ASUS A7V600
Hi,
At 10:50 AM 2/05/2001 +0200, Ingo Molnar wrote:
>i think Zach's phhttpd is an important milestone as well, it's the first
>userspace webserver that shows how to use event-based, sigio-based async
>networking IO and sendfile() under Linux. (I believe it had some
>performance problems related
Hi,
At 10:50 AM 2/05/2001 +0200, Ingo Molnar wrote:
i think Zach's phhttpd is an important milestone as well, it's the first
userspace webserver that shows how to use event-based, sigio-based async
networking IO and sendfile() under Linux. (I believe it had some
performance problems related to
getsockopt(fd, SOL_IP, IP_TOS, ..
cheers,
lincoln.
At 03:00 PM 7/03/2001 +1100, David Luyer wrote:
>I've scrolled through various code in net/ipv4, and I can't see how to query
>the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which
>initiated the connection).
>
At 07:03 PM 1/03/2001 +0300, Hans Reiser wrote:
> > > They know that iMimic's polymix performance on Linux 2.2.* is half
> what it is on
> > > BSD. Has the Linux 2.4 networking code caught up to BSD?
> > >
> > > Can I tell them not to worry about the Linux networking code
> strangling their
>
At 07:03 PM 1/03/2001 +0300, Hans Reiser wrote:
They know that iMimic's polymix performance on Linux 2.2.* is half
what it is on
BSD. Has the Linux 2.4 networking code caught up to BSD?
Can I tell them not to worry about the Linux networking code
strangling their
webcache
Hi,
At 02:33 PM 28/01/2001 -0700, Dax Kelson wrote:
>Here is the fix for PIX:
>
>(see
>http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds23698)
> Bud ID: CSCds23698
> Headline: PIX sends RSET in response to tcp connections with ECN
> bits set
> Product: PIX
>
Hi,
At 02:33 PM 28/01/2001 -0700, Dax Kelson wrote:
Here is the fix for PIX:
(see
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds23698)
Bud ID: CSCds23698
Headline: PIX sends RSET in response to tcp connections with ECN
bits set
Product: PIX
Component:
Hi,
At 01:06 AM 25/01/2001 -0800, David S. Miller wrote:
>Juri Haberland writes:
> > Forget it. I mailed them and this is the answer:
> >
> > "As ECN is not a widely used internet standard, and as Cisco does not
> > have a stable OS for their routers that accepts ECN, anyone attempting
> >
Hi,
At 01:06 AM 25/01/2001 -0800, David S. Miller wrote:
Juri Haberland writes:
Forget it. I mailed them and this is the answer:
"As ECN is not a widely used internet standard, and as Cisco does not
have a stable OS for their routers that accepts ECN, anyone attempting
to access
hi,
At 04:56 PM 20/01/2001 +0200, Kai Henningsen wrote:
[EMAIL PROTECTED] (dean
gaudet) wrote on 18.01.01 in
<[EMAIL PROTECTED]>:
> i'm pretty sure the actual use of pipelining is pretty
disappointing.
> the work i did in apache preceded the widespread use of HTTP/1.1 and
we
What widespread
hi,
At 04:56 PM 20/01/2001 +0200, Kai Henningsen wrote:
[EMAIL PROTECTED] (dean
gaudet) wrote on 18.01.01 in
[EMAIL PROTECTED]:
i'm pretty sure the actual use of pipelining is pretty
disappointing.
the work i did in apache preceded the widespread use of HTTP/1.1 and
we
What widespread use of
Hi,
At 05:28 PM 31/12/2000 +0200, Jussi Hamalainen wrote:
>On Sun, 31 Dec 2000, Mikael Abrahamsson wrote:
>
> > When the linux box does TCP to the outside it'll use the MTU of
> > the tunnel (default route is the tunnel) and thus works perfectly
> > (since TCP MSS will be set low enough to fit
Hi,
At 05:28 PM 31/12/2000 +0200, Jussi Hamalainen wrote:
On Sun, 31 Dec 2000, Mikael Abrahamsson wrote:
When the linux box does TCP to the outside it'll use the MTU of
the tunnel (default route is the tunnel) and thus works perfectly
(since TCP MSS will be set low enough to fit into the
At 10:39 PM 23/10/2000 -0700, Linus Torvalds wrote:
>First, let's see what is so nice about "select()" and "poll()". They do
>have one _huge_ advantage, which is why you want to fall back on poll()
>once the RT signal interface stops working. What is that?
RT methods are bad if they consume too
At 10:39 PM 23/10/2000 -0700, Linus Torvalds wrote:
First, let's see what is so nice about "select()" and "poll()". They do
have one _huge_ advantage, which is why you want to fall back on poll()
once the RT signal interface stops working. What is that?
RT methods are bad if they consume too
At 02:09 PM 19/10/2000 -0400, Mark Haney wrote:
> > Feel free to send complaints to [EMAIL PROTECTED] and get his account
> > yanked for abuse of mailing lists.
>
>http://www.ilan.net/contact.htm for a nice list of addresses to send
>complaints to.
the original email came from 216.27.3.45.
a
At 02:09 PM 19/10/2000 -0400, Mark Haney wrote:
Feel free to send complaints to [EMAIL PROTECTED] and get his account
yanked for abuse of mailing lists.
http://www.ilan.net/contact.htm for a nice list of addresses to send
complaints to.
the original email came from 216.27.3.45.
a quick grep
fix will be
forthcoming in a future interim release.
back to linux kernel issues,
cheers,
lincoln.
--
Lincoln Dale Content Services Business Unit
[EMAIL PROTECTED] cisco Systems, Inc. | |
||||
+1 (408) 525-1
in a future interim release.
back to linux kernel issues,
cheers,
lincoln.
--
Lincoln Dale Content Services Business Unit
[EMAIL PROTECTED] cisco Systems, Inc. | |
||||
+1 (408) 525-1274
awful right now, but i hope these can be cleaned up over time.
network cards which offload the IP & TCP checksum calculation isn't even
required; provided the incoming checksum is preserved, the original pseudo
TCP header can be "reversed out" without having to re-read the entir
.
network cards which offload the IP TCP checksum calculation isn't even
required; provided the incoming checksum is preserved, the original pseudo
TCP header can be "reversed out" without having to re-read the entire
packet payloads again.
cheers,
lincoln.
--
Lincoln Dale
real problem with threads are
that it is too easy to write bad code using them.
caveat emptor.
cheers,
lincoln.
--
Lincoln Dale Content Services Business Unit
[EMAIL PROTECTED] cisco Systems, Inc. | |
||
36 matches
Mail list logo
