Bernd,
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 running wi
Bernd Eckenfels wrote:
In article <[EMAIL PROTECTED]> you wrote:
I mean, nvidia people also use propietary code in the kernel (probably
violating the GPL anyway) and don't do such things.
The Linux kernel allows binary drivers, you just have to live with a limited
number of exported s
Diego Calleja wrote:
El Wed, 31 Aug 2005 14:27:47 -0600,
"Jeff V. Merkey" <[EMAIL PROTECTED]> escribió:
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the he
512 is not enough. It has to be larger. I just tried 512 and it still
limits the data rates.
Jeff
Jens Axboe wrote:
On Wed, Aug 31 2005, jmerkey wrote:
I have seen an 80GB/sec limitation in the kernel unless this value is
changed in the SCSI I/O layer
for 3Ware and other controllers
Don't do this. BLKDEV_MIN_RQ sets the size of the mempool reserved
requests and will only get slightly used in low memory conditions, so
most memory will probably be wasted.
Change /sys/block/xxx/queue/nr_requests
Tom Callahan
TESSCO Technologies
(443)-506-6216
[EMAIL PROTECTED]
I have seen an 80GB/sec limitation in the kernel unless this value is
changed in the SCSI I/O layer
for 3Ware and other controllers during testing of 2.6.X series kernels.
Change these values in include/linux/blkdev.h and performance goes from
80MB/S to over 670MB/S on the 3Ware controller.
This is a very good idea.
Jeff
Venkatesh Pallipadi wrote:
The specifications that talk about E820 map doesn't have an upper limit
on the number of E820 entries. But, today's kernel has a hard limit of 32.
With increase in memory size, we are seeing the number of E820 entries
reaching close to 32. P
6 1291904 8377 4815
0 100 0 0
0 0 0 50240 6848 1580940800 304 3136 8556 5088 1
26 0 74
0 0 0 50304 6848 1580940800 0 0 8572 5181
0 0 0 100
The average rate here is again pretty close to 550MB/s, it just writes
the blocks in "bursts
For 3Ware, you need to chage the queue depths, and you will see
dramatically improved performance. 3Ware can take requests
a lot faster than Linux pushes them out. Try changing this instead, you
won't be going to sleep all the time waiting on the read/write
request queues to get "unstarved".
/l
I disabled the FIFO resetting code and am running tests. See what
happens. I am on 2.6 not
2.4 so it could be a problem there. At any rate, I will see if the
problem goes away.
Jeff
Willy Tarreau wrote:
On Sat, Apr 02, 2005 at 11:58:44PM -0700, jmerkey wrote:
It works fine with the Intel
Jeff Garzik wrote:
jmerkey wrote:
With linux 2.6.9 running at 192 MB/S network loading and protocol
splitting drivers routing packets out of
a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4
ports, the adaptec starfire driver goes into
constant Tx FIFO reconfiguration mode and
her 4-port NIC (tulip or sun for example) ? Sun
QFE would be the most interesting to test as it also supports 64 bits /
66 MHz.
Regards,
Willy
On Sat, Apr 02, 2005 at 09:41:28PM -0700, jmerkey wrote:
With linux 2.6.9 running at 192 MB/S network loading and protocol
splitting drivers routing packet
With linux 2.6.9 running at 192 MB/S network loading and protocol
splitting drivers routing packets out of
a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports,
the adaptec starfire driver goes into
constant Tx FIFO reconfiguration mode and after 3-4 days of constantly
resetti
With linux 2.6.9 running at 192 MB/S network loading and protocol
splitting drivers routing packets out of
a 2.6.9 device at full 100 mb/s (12.5 MB/S) simultaneously over 4 ports,
the adaptec starfire driver goes into
constant Tx FIFO reconfiguration mode and after 3-4 days of constantly
resetti
Arjan van de Ven wrote:
On Mon, Mar 21, 2005 at 11:54:10AM -0700, jmerkey wrote:
Arjan van de Ven wrote:
On Mon, 2005-03-21 at 11:35 -0700, jmerkey wrote:
In case nobody has already reported it, clone() and pthread_create()
return SIGSEGV faults
when a 2.4.29 kernel on the Taroon
Arjan van de Ven wrote:
On Mon, 2005-03-21 at 11:35 -0700, jmerkey wrote:
In case nobody has already reported it, clone() and pthread_create()
return SIGSEGV faults
when a 2.4.29 kernel on the Taroon Red Hat release.
you're running an OS that requires a kernel with NPTL support. Ye
In case nobody has already reported it, clone() and pthread_create()
return SIGSEGV faults
when a 2.4.29 kernel on the Taroon Red Hat release.
Jeff
-
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:
Bernd Eckenfels wrote:
In article <[EMAIL PROTECTED]> you wrote:
You have to ignore the partition table contents for ending cylinder.
Good Question. Where are the standard tools in FC2 and FC3 for these types?
Jeff
Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe lin
Andrew Morton wrote:
jmerkey <[EMAIL PROTECTED]> wrote:
>I don't recall you reporting any of them. How can we expect to fix
>anything if we aren't told about it?
>
>
>
I report them when I can't get around them myself. I've been able to get
around mos
Andrew Morton wrote:
jmerkey <[EMAIL PROTECTED]> wrote:
I am running the DSFS file system as a 7 TB file system on 2.6.9.
On a 32-bit CPU?
Yep.
There are a host of problems with the current VFS,
I don't recall you reporting any of them. How can we expect to fix
any
You have to ignore the partition table contents for ending cylinder. Use
the following instead. You also
have to write your own FS or modify the partition code in Linux or you
won't be able to use the storage. This
config option listed in the previous post only enables 64 bit LBA
addressing, it
I am running the DSFS file system as a 7 TB file system on 2.6.9. There
are a host
of problems with the current VFS, ad I have gotten around most of them
by **NOT** using the linux page cache interface. The VFS I am using
creates a virtual represeation of the files and it's own cache. You need
James Simmons wrote:
Patent law in the US is based on section 113 of the United States
Constitution, and patents
are not going away. Live with guys. The best way to win the patent
wars is for people
who do Linux development to file their own patents and put some stakes
in the ground.
I
You guys keep saying, "stop the patents" but this is insanity. It's
like all these big companies
used patents like swords and are hemming linux in, and Linux stands
naked and defenseless.
You guys need to get your own swords and fight -- start filing
patents -- go to this new law
center "South
Jeffrey E. Hundstad wrote:
linux-2.6.10 has some bio problems that are fixed in the current
linux-2.6.11 release candidates. The bio problems wreaked havoc with
XFS and there were people reporting EXT3 problems as well with this
bug. I'd recommend trying the latest release candidate and see if
jmerkey wrote:
Jean-Marc Valin wrote:
Le lundi 28 février 2005 à 08:31 -0700, jmerkey a écrit :
I see this problem infrequently on systems that have low memory
conditions and
with heavy swapping.I have not seen it on 2.6.9 but I have seen
it on 2.6.10.
My machine has 1 GB RAM and I
Jean-Marc Valin wrote:
Le lundi 28 février 2005 à 08:31 -0700, jmerkey a écrit :
I see this problem infrequently on systems that have low memory
conditions and
with heavy swapping.I have not seen it on 2.6.9 but I have seen it
on 2.6.10.
My machine has 1 GB RAM and I wasn't
I see this problem infrequently on systems that have low memory
conditions and
with heavy swapping.I have not seen it on 2.6.9 but I have seen it
on 2.6.10.
Jeff
Jean-Marc Valin wrote:
Please try stock kernel. 2.6.11-rc3 onwards should be fine. - I saw a similar
problem while running 2.6.1
His point and direction (or lack thereof) are easy to see, and
consistent. Linux has been a war of attrition
with an interesting rat's maze model of human intereaction -- always
interesting to see new mice traverse the
maze (only there's no cheese at the end of this maze -- just the smell
of che
29 matches
Mail list logo
