Re: Oops in 2.4.0-ac5

2001-01-10 Thread Ingo Molnar
On Wed, 10 Jan 2001, Alan Cox wrote: it. I could never persuade Ingo to use wrmsr_eio() and check the return code, maybe this will change his mind. Extract from kdb v1.7. I have a patch from Ingo to fix this one properly. Its just getting tested i prefer clear oopses and bug reports

[patch] highmem-2.4.0-A0 (was: Re: 2.4.0-ac6: mm/vmalloc.c compileerror)

2001-01-11 Thread Ingo Molnar
On Thu, 11 Jan 2001, Frank Davis wrote: Hello, The following error occurred while compiling 2.4.0-ac6. [...] vmalloc.c: In function `get_vm_area': vmalloc.c:188: `PKMAP_BASE' undeclared (first use in this function) you are compiling with HIGHMEM enabled (which makes sense only if you

Re: Oops in 2.4.0-ac5

2001-01-11 Thread Ingo Molnar
On Thu, 11 Jan 2001, David Woodhouse wrote: The bug here seems to be that we're using the same bit (X86_FEATURE_APIC) to report two _different_ features. i think that the AMD APIC is truly 'compatible', but we are trying to enable the APIC and program performance counters in an Intel-way.

Re: Updated zerocopy patch up on kernel.org

2001-01-11 Thread Ingo Molnar
On Tue, 9 Jan 2001, David S. Miller wrote: Nothing interesting or new, just merges up with the latest 2.4.1-pre1 patch from Linus. ftp.kernel.org:/pub/linux/kernel/people/davem/zerocopy-2.4.1p1-1.diff.gz I haven't had any reports from anyone, which must mean that it is working perfectly

[patch] Lowlatency Patch for 2.4.0-ac6 and 2.4.1-pre2

2001-01-11 Thread Ingo Molnar
a new version against recent 2.4 kernels of my multimedia-lowlatency patchset is now available. These patches are the 2.4-adapted versions of my 2.2 lowlatency patch, which project has now reached an age of 1.5+ years. the lowlatency patch against 2.4.0-ac6 can also be found at:

Re: [PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1

2001-01-09 Thread Ingo Molnar
On Tue, 9 Jan 2001, Stephen Frost wrote: Now, the interesting bit here is that the processes can grow to be pretty large (200M+, up as high as 500M, higher if we let it ;) ) and what happens with MOSIX is that entire processes get sent over the wire to other machines for work. MOSIX

lies, lies and web benchmarks :-)

2001-01-12 Thread Ingo Molnar
On Thu, 11 Jan 2001, Christoph Lameter wrote: I got into a bragging game whose webserver is the fastest with Jim Nelson one of the authors of the boa webserver. We finally settled on the Zeus test to decide the battle. may i add my (hopefully comparable) TUX 2.0 numbers to this bragging

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

2001-01-12 Thread Ingo Molnar
On Fri, 12 Jan 2001, Manfred Spraul wrote: The PPro local apic documentation says: The processor's local APIC includes an in-service entry and a holding entry for each priority level. To avoid losing interrupts, software should allocate no more than 2 interrupt vectors per priority.

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardware

2001-01-12 Thread Ingo Molnar
On Fri, 12 Jan 2001, Manfred Spraul wrote: 2.4 spreads the vectors for the external (hardware, from io apic) interrupts, but 5 ipi vectors have the same priority: reschedule, call function, tlb invalidate, apic error, spurious interrupt. my reading of the errata is that the lost APIC timer

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

2001-01-12 Thread Ingo Molnar
On Fri, 12 Jan 2001, Linus Torvalds wrote: [...] Ingo, what was the focus-cpu thing? well, some time ago i had an ne2k card in an SMP system as well, and found this very problem. Disabling/enabling focus-cpu appeared to make a difference, but later on i made experiments that show that in both

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

2001-01-12 Thread Ingo Molnar
On Fri, 12 Jan 2001, Frank de Lange wrote: In addition, I patched apic.c (focus cpu enabled) In addition, I patched io_apic ((TARGET_CPUS 0xff) please try it with the focus CPU enabling change (we want to enable that feature, i only disabled it due to the stuck-ne2k bug), but with

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

2001-01-12 Thread Ingo Molnar
On Fri, 12 Jan 2001, Frank de Lange wrote: WITH or WITHOUT the changed 8390 driver? I can already give you the results for running WITH the changed driver: it works. I have not yet tried it WITHOUT the changed 8390 driver (so that would be stock 8390, patched apic.c, stock io_apic.c).

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

2001-01-12 Thread Ingo Molnar
On Fri, 12 Jan 2001, Frank de Lange wrote: BTW, does this (TARGET_CPUS cpu_online_mask) not wreak havoc with systems with hot-pluggable CPUs (many Suns, etc...)? Wouldn;t it be better to make this a config option (like the optional PCI fixes for crappy BIOSs)? ? this is x86-only code.

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

2001-01-12 Thread Ingo Molnar
On Fri, 12 Jan 2001, Frank de Lange wrote: It is. As I already mentioned in other messages, I already tested with JUST the patched 8390.c driver, no other patches. It was stable. I then patched apic.c AND io_apic.c, which did not introduce new instabilities. Unless you think that reverting

Re: QUESTION: Network hangs with BP6 and 2.4.x kernels, hardwarerelated?

2001-01-12 Thread Ingo Molnar
On Fri, 12 Jan 2001, Frank de Lange wrote: PATCHED 8390.c (using irq_safe spinlocks instead of disable_irq) PATCHED apic.c (focus cpu ENABLED) STOCK io_apic.c No problems under heavy network load. Gentleman, this (the patch to 8390.c) seems to fix the problem. great. Back when i had the

Re: Updated zerocopy patch up on kernel.org

2001-01-11 Thread Ingo Molnar
On Tue, 9 Jan 2001, David S. Miller wrote: Is there any value to supporting fragments in a driver which doesn't do hardware checksumming? IIRC Alexey had a patch to do such for Tulip, but I don't see it in the above patchset. I'm actually considering making the SG w/o hwcsum

Re: Ingo's RAID patch for 2.2.18 final?

2001-01-14 Thread Ingo Molnar
On 13 Jan 2001 [EMAIL PROTECTED] wrote: What is at http://www.kernel.org/pub/linux/kernel/people/mingo/ look official enough to me... raid-2.2.18-B0 12-Jan-2001 10:18 392k yep, it is the 'official' 2.2.18 RAID patch. Ingo - To unsubscribe from this list: send the

Re: Is sendfile all that sexy?

2001-01-14 Thread Ingo Molnar
On Sun, 14 Jan 2001, jamal wrote: regular ttcp, no ZC and no sendfile. [...] Throughput: ~99MB/sec (for those obsessed with Mbps ~810Mbps) CPU abuse: server side 87% client side 22% [...] sendfile server. - throughput: 86MB/sec - CPU: server 100%, client 17% i believe what you are

Re: Is sendfile all that sexy?

2001-01-14 Thread Ingo Molnar
On 14 Jan 2001, Linus Torvalds wrote: Does anybody but apache actually use it? There is a Samba patch as well that makes it sendfile() based. Various other projects use it too (phttpd for example), some FTP servers i believe, and khttpd and TUX. Ingo - To unsubscribe from this list:

Re: Is sendfile all that sexy?

2001-01-14 Thread Ingo Molnar
On Sun, 14 Jan 2001, Linus Torvalds wrote: There is a Samba patch as well that makes it sendfile() based. Various other projects use it too (phttpd for example), some FTP servers i believe, and khttpd and TUX. At least khttpd uses "do_generic_file_read()", not sendfile per se. I assume

[patch] fixes for RAID1/RAID5 hot-add/hot-remove, 2.4.0-ac9

2001-01-15 Thread Ingo Molnar
- the attached patch (against -ac9) fixes a bug in the RAID1 and RAID4/5 code that made raidhotremove fail under certain (rare) circumstances. Please apply. Ingo --- linux/drivers/md/raid1.c.orig Mon Dec 11 22:19:35 2000 +++ linux/drivers/md/raid1.cMon Jan 15 14:45:35

Re: Is sendfile all that sexy?

2001-01-15 Thread Ingo Molnar
On Mon, 15 Jan 2001, Jonathan Thackray wrote: It's a very useful system call and makes file serving much more scalable, and I'm glad that most Un*xes now have support for it (Linux, FreeBSD, HP-UX, AIX, Tru64). The next cool feature to add to Linux is sendpath(), which does the open()

[patch] sendpath() support, 2.4.0-test3/-ac9

2001-01-15 Thread Ingo Molnar
()+sendfile()? Ingo --- linux/mm/filemap.c.orig Mon Jan 15 22:43:21 2001 +++ linux/mm/filemap.c Mon Jan 15 23:09:55 2001 @@ -39,6 +39,8 @@ * page-cache, 21.05.1999, Ingo Molnar [EMAIL PROTECTED] * * SMP-threaded pagemap-LRU 1999, Andrea Arcangeli [EMAIL PROTECTED

Re: 4G SGI quad Xeon - memory-related slowdowns

2001-01-15 Thread Ingo Molnar
On 15 Jan 2001, Linus Torvalds wrote: The performance problem is _probably_ due to the kernel having to double-buffer the IO requests, coupled with bad MTRR settings (ie memory above the 4GB range is probably marked as non-cacheable or something, which means that you'll get really bad

Re: [patch] sendpath() support, 2.4.0-test3/-ac9

2001-01-16 Thread Ingo Molnar
On Mon, 15 Jan 2001, dean gaudet wrote: just for kicks i've implemented sendpath() support. _syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size) hey so how do you implement transmit timeouts with sendpath() ? (i.e. drop the client after 30 seconds of no

'native files', 'object fingerprints' [was: sendpath()]

2001-01-16 Thread Ingo Molnar
On Mon, 15 Jan 2001, Linus Torvalds wrote: _syscall4 (int, sendpath, int, out_fd, char *, path, off_t *, off, size_t, size) You want to do a non-blocking send, so that you don't block on the socket, and do some simple multiplexing in your server. And "sendpath()" cannot do that without

Re: 'native files', 'object fingerprints' [was: sendpath()]

2001-01-16 Thread Ingo Molnar
On Tue, 16 Jan 2001, Andi Kleen wrote: On Tue, Jan 16, 2001 at 10:48:34AM +0100, Ingo Molnar wrote: this is a safe, very fast [ O(1) ] object-permission model. (it's a variation of a former idea of yours.) A process can pass object fingerprints and kernel pointers to other processes too

O_ANY [was: Re: 'native files', 'object fingerprints' [was:sendpath()]]

2001-01-16 Thread Ingo Molnar
On Tue, 16 Jan 2001, Andi Kleen wrote: the 'allocate first free file descriptor number' rule for normal Unix files? Not sure I follow. You mean dup2() ? I'm sure you know this: when there are thousands of files open already, much of the overhead of opening a new file comes from the

Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was:sendpath()]]

2001-01-16 Thread Ingo Molnar
On Tue, 16 Jan 2001, Ingo Molnar wrote: struct lazy_filedesc { int fd; struct file *file; } in fact "struct file" can (ab)used for this, no need for new structures or new fields. Eg. file-f_flags contains the cached descriptor-informa

Re: O_ANY [was: Re: 'native files', 'object fingerprints' [was:sendpath()]]

2001-01-16 Thread Ingo Molnar
On Tue, 16 Jan 2001, Peter Samuelson wrote: [Ingo Molnar] - probably the most radical solution is what i suggested, to completely avoid the unique-mapping of file structures to an integer range, and use the address of the file structure (and some cookies) as an identification

Re: Is sendfile all that sexy?

2001-01-16 Thread Ingo Molnar
On Tue, 16 Jan 2001, Felix von Leitner wrote: I don't know how Linux does it, but returning the first free file descriptor can be implemented as O(1) operation. only if special allocation patters are assumed. Otherwise it cannot be a generic O(1) solution. The first-free rule adds an

Re: Is sendfile all that sexy?

2001-01-16 Thread Ingo Molnar
On Tue, 16 Jan 2001, Felix von Leitner wrote: I don't know how Linux does it, but returning the first free file descriptor can be implemented as O(1) operation. to put it more accurately: the requirement is to be able to open(), use and close() an unlimited number of file descriptors with

Re: Hi memory support in 2.4 not working correctly.

2001-01-17 Thread Ingo Molnar
On Wed, 17 Jan 2001, Micah Gorrell wrote: I have a compaq 8 way server with 4 gigs of memory. I am running 2.4.0 and everything works just fine (except the gig - I'm still fighting with that) The only strange thing that I am seeing is that I only see 3.3 gigs of memory instead of the full

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Wed, 17 Jan 2001, dean gaudet wrote: with the linux TCP_CORK API you only get one trailing small packet. in case you haven't heard of TCP_CORK -- when the cork is set, the kernel is free to send any maximum size packets it can form, but has to hold on to the stragglers until userland

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Wed, 17 Jan 2001, Rick Jones wrote: i'd heard interesting generalities but no specifics. for instance, when the send is small, does TCP wait exclusively for the app to flush, or is there an "if all else fails" sort of timer running? yes there is a per-socket timer for this. According to

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Wed, 17 Jan 2001, Linus Torvalds wrote: (I also had one person point out that BSD's have the notion of TCP_NOPUSH, which does almost what TCP_CORK does under Linux, except it doesn't seem to have the notion of uncorking - you can turn NOPUSH off, but apparently it doesn't affect queued

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Wed, 17 Jan 2001, Rick Jones wrote: certainly, i see by your examples how cork can make life easier on the developer - they can putc() the reply if they want. for a persistent http connection, there would be the cork and uncork each time, for a pipelined connection, it is basically a

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Thu, 18 Jan 2001, Linus Torvalds wrote: Yeah, and how are you going to teach a perl CGI script that writes to stdout to use it? yep, correct. But you can have TCP_CORK behavior from user-space (by setting the cork flag in user-space and writing it for all network output), while you cannot

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Thu, 18 Jan 2001, Linus Torvalds wrote: Remember the UNIX philosophy: everything is a file. MSG_MORE completely breaks that, because the only way to use it is with send[msg](). It's absolutely unusable with something like a traditional UNIX "anonymous" application that doesn't know or

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Thu, 18 Jan 2001 [EMAIL PROTECTED] wrote: Actually, TUX-1.1 (Ingo, do I not lie, did you not kill this code?) does this. It does not ack quickly, when complete request is received and still not answered, so that all the redundant acks disappear. (it's TUX 2.0 meanwhile), and yes, TUX

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Thu, 18 Jan 2001, Linus Torvalds wrote: I think Andrea was thinking more of the case of the anonymous IO generator, and having the "controller" program thgat keeps the socket always in CORK mode, but uses SIOCPUSH when it doesn't know what teh future access patterns will be. yep.

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Thu, 18 Jan 2001, Andrea Arcangeli wrote: { int val = 1; setsockopt(req-sock, IPPROTO_TCP, TCP_CORK, (char *)val,sizeof(val)); val = 0; setsockopt(req-sock, IPPROTO_TCP, TCP_CORK, (char *)val,sizeof(val));

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Thu, 18 Jan 2001, Andrea Arcangeli wrote: This is a possible slow (but userspace based) implementation of SIOCPUSH: of course this is what i meant. Lets stop wasting time on this, ok? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Thu, 18 Jan 2001, Andrea Arcangeli wrote: BTW, the simmetry between getsockopt/setsockopt further bias how SIOCPUSH doesn't fit into the setsockopt options but it fits very well into the ioctl categorty instead. There's simply no state one can return via getsockopt for the SIOCPUSH

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Thu, 18 Jan 2001, Andrea Arcangeli wrote: Agreed. However since TCP_CORK logic is more generic than MSG_MORE [...] why? TCP_CORK is equivalent to MSG_MORE, it's just a different representation of the same issue. TCP_CORK needs an extra syscall (in the case of a push event - which might be

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

2001-01-18 Thread Ingo Molnar
On Thu, 18 Jan 2001, Andrea Arcangeli wrote: I'm all for TCP_CORK but it has the disavantage of two syscalls for doing the flush of the outgoing queue to the network. And one of those two syscalls is spurious. [...] i believe a network-conscious application should use MSG_MORE - that has no

Re: Is sendfile all that sexy?

2001-01-21 Thread Ingo Molnar
On Sun, 21 Jan 2001, James Sutherland wrote: For many applications, yes - but think about a file server for a moment. 99% of the data read from the RAID (or whatever) is really aimed at the appropriate NIC - going via main memory would just slow things down. patently wrong. Compare the

[patch] wait4-2.4.0-A0

2001-01-22 Thread Ingo Molnar
the attached patch (against -pre9) fixes a possibly dangerous sys_wait4() prototype mismatch. Ingo --- linux/include/linux/sched.h.origMon Jan 22 17:28:36 2001 +++ linux/include/linux/sched.h Mon Jan 22 17:29:17 2001 @@ -563,6 +563,7 @@ #define wake_up_interruptible_all(x)

[patch] new, scalable timer implementation, smptimers-2.4.0-B1

2001-01-28 Thread Ingo Molnar
a new, 'ultra SMP scalable' implementation of Linux kernel timers is now available for download: http://www.redhat.com/~mingo/scalable-timers/smptimers-2.4.0-B1 the patch is against 2.4.1-pre10 or ac12. The timer design in this implementation is a work of David Miller, Alexey Kuznetsov and

[patch] raid-B1, 2.4.1-pre11, fixes, cleanups

2001-01-29 Thread Ingo Molnar
On Tue, 30 Jan 2001, Neil Brown wrote: -#define MAX_MD_BOOT_DEVS 8 +#define MAX_MD_BOOT_DEVS MAX_MD_DEVS Actually, this is not fine. Check the code that says: indeed - it will work only up to 32 devices. i've fixed the code to not have this assumption - it's init-time code only

Re: Desk check of raid5.c patch from mtew@cds.duke.edu?

2001-01-30 Thread Ingo Molnar
On Mon, 29 Jan 2001, Quim K Holland wrote: I've been following the recent 2.4.1-pre series and am wondering why the following one-liner (obviously correct) patch has not been applied. [...] - return_ok = bh-b_reqnext; + return_fail = bh-b_reqnext; oops - i do

Re: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing todo with ECN)

2001-01-30 Thread Ingo Molnar
On Tue, 30 Jan 2001, jamal wrote: Kernel | tput | sender-CPU | receiver-CPU | - 2.4.0-pre3 | 99MB/s | 87% | 23% | NSF||| | -

Re: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing todo with ECN)

2001-01-30 Thread Ingo Molnar
On Tue, 30 Jan 2001, jamal wrote: - is this UDP or TCP based? (UDP i guess) TCP well then i'd suggest to do: echo 10 10 10 /proc/sys/net/ipv4/tcp_wmem does this make any difference? Ingo - To unsubscribe from this list: send the line "unsubscribe

Re: Still not sexy! (Re: sendfile+zerocopy: fairly sexy (nothing todo with ECN)

2001-01-31 Thread Ingo Molnar
On Wed, 31 Jan 2001, Malcolm Beattie wrote: Without the raised tcp_wmem setting I was getting 81 MByte/s. With tcp_wmem set as above I got 86 MByte/s. Nice increase. Any other setting I can tweak apart from {r,w}mem_max and tcp_{w,r}mem? The CPU on the client (350 MHz PII) is the

Re: start_thread question...

2001-05-20 Thread Ingo Molnar
On Sun, 20 May 2001, Dave Airlie wrote: I'm implementing start_thread for the VAX port and am wondering does start_thread have to return to load_elf_binary? I'm working on the init thread and what is happening is it is returning the whole way back to the execve caller .. which I know

Re: 2.4.4 del_timer_sync oops in schedule_timeout

2001-05-20 Thread Ingo Molnar
On Sat, 19 May 2001, Jacob Luna Lundberg wrote: This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in. Unable to handle kernel paging request at virtual address 78626970 this appears to be some sort of DMA-corruption or other memory scribble problem. hexa 78626970 is ASCII pibx,

Re: 2.4.4 del_timer_sync oops in schedule_timeout

2001-05-20 Thread Ingo Molnar
On Sun, 20 May 2001, Jacob Luna Lundberg wrote: Unable to handle kernel paging request at virtual address 78626970 this appears to be some sort of DMA-corruption or other memory scribble problem. hexa 78626970 is ASCII pibx, which shows in the direction of some sort of disk-related DMA

Re: Linux-2.4.5

2001-05-26 Thread Ingo Molnar
On Sat, 26 May 2001, Andrea Arcangeli wrote: On Sat, May 26, 2001 at 02:11:15PM -0400, Ben LaHaise wrote: No. It does not fix the deadlock. Neither does the patch you posted. can you give a try if you can deadlock 2.4.5aa1 just in case, and post a SYSRQ+T + system.map if it still

[patch] severe softirq handling performance bug, fix, 2.4.5

2001-05-26 Thread Ingo Molnar
i've been seeing really bad average TCP latencies on certain gigabit cards (~300-400 microseconds instead of the expected 100-200 microseconds), ever since softnet went into the main kernel, and never found a real explanation for it, until today. the problem always went away when i tried to use

Re: [RFD w/info-PATCH] device arguments from lookup, partion code

2001-05-20 Thread Ingo Molnar
On Sun, 20 May 2001, Alexander Viro wrote: Linus, as much as I'd like to agree with you, you are hopeless optimist. 90% of drivers contain code written by stupid gits. 90% of drivers contain code written by people who do driver development in their spare time, with limited resources, most of

Re: [patch] softirq-2.4.5-B0

2001-05-27 Thread Ingo Molnar
On Sun, 27 May 2001, David S. Miller wrote: Hooray, some sanity in this thread finally :-) [ finally i had some sleep after a really long debugging session :-| ] the attached softirq-2.4.5-B0 patch fixes this problem by calling do_softirq() from local_bh_enable() [if the bh count is

Re: [patch] severe softirq handling performance bug, fix, 2.4.5

2001-05-27 Thread Ingo Molnar
On Sun, 27 May 2001, Andrea Arcangeli wrote: Yes the stock kernel. yep you are right. i had this fixed too at a certain point, there is one subtle issue: under certain circumstances tasklets re-activate the tasklet softirq(s) from within the softirq handler, which leads to infinite loops if

[patch] ioapic-2.4.5-A1

2001-05-29 Thread Ingo Molnar
the attached ioapic-2.4.5-A1 patch includes a number of important IO-APIC related fixes (against 2.4.5-ac3): - correctly handle bridged devices that are not listed in the mptable directly. This fixes eg. dual-port eepro100 devices on Compaq boxes with such PCI layout: -+-[0d]---0b.0

[patch] raid-2.4.5-A0, minor fix

2001-05-29 Thread Ingo Molnar
the attached patch (against 2.4.5-ac3) fixes a compiler warning (triggered by gcc 2.96) in the RAID include files. Ingo --- linux/include/linux/raid/md_k.h.origTue May 29 12:50:30 2001 +++ linux/include/linux/raid/md_k.h Tue May 29 12:50:40 2001 @@ -38,6 +38,7 @@

[patch] softirq-2.4.5-E5

2001-05-29 Thread Ingo Molnar
the attached softirq-2.4.5-E5 patch (against 2.4.5-ac3) tries to solve all softirq, tasklet and scheduling latency problems i could identify while testing TCP latencies over gigabit connections. The list of problems, as of 2.4.5-ac3: - the need_resched check in the arch/i386/kernel/entry.S

Re: IRQ handling in SMP environment, kernel 2.4.3

2001-05-29 Thread Ingo Molnar
On Tue, 29 May 2001, Hilik Stein wrote: I am running a Linux machine with a 1GB Ethernet card which takes a huge amount of packets, which results in many HW interrupts. is it possible to make sure that only CPU #1 handles all the hardware interrupts generated by the NIC ? or even all the

Re: Emulate RDTSC

2001-05-29 Thread Ingo Molnar
On Tue, 29 May 2001, Jaswinder Singh wrote: What is the nice way (in accuracy and performance) to emulate RDTSC in Linux for those architectures who dont support RDTSC like in Hitachi SH Processors. if the hardware provides no way to get some accurate estimation of current time, then there

Re: [ PATCH ]: disable pcspeaker kernel: 2.4.2 - 2.4.5

2001-05-30 Thread Ingo Molnar
By making this (logical, and needed) feature unconditional, your patch's size and complexity is reduced by 80%. (see the attached pc_speaker.patch2) Ingo diff -u --recursive linux-2.4.5/drivers/char/vt.c linux-2.4.5-nc/drivers/char/vt.c --- linux-2.4.5/drivers/char/vt.c Fri

Re: [ PATCH ]: disable pcspeaker kernel: 2.4.2 - 2.4.5

2001-05-30 Thread Ingo Molnar
less code / one int more in the kernel or more code and #ifs / one int less in the kernel if the #ifdefs bloat the code 4 times the size of the simple patch, then we obviously want 4 bytes more in the kernel. And what about the code from kernel/sys.c ? The version you provided doesn't

Re: pte_page

2001-05-30 Thread Ingo Molnar
On Wed, 30 May 2001 [EMAIL PROTECTED] wrote: I use the 'pgt_offset', 'pmd_offset', 'pte_offset' and 'pte_page' inside a module to get the physical address of a user space virtual address. The physical address returned by 'pte_page' is not page aligned whereas the virtual address was page

Re: [ PATCH ]: disable pcspeaker kernel: 2.4.2 - 2.4.5

2001-05-30 Thread Ingo Molnar
On Wed, 30 May 2001, Nico Schottelius wrote: the default value is 0, that is good enough. hmm.. I don't think so... value of 1 would be much better, because 0 normally disables the speaker. i confused the value. Yes, an initialization to 1 would be the correct, ie.: +++

Re: pte_page

2001-05-30 Thread Ingo Molnar
On Wed, 30 May 2001, Pete Wyckoff wrote: __pa(page_address(pte_page(pte))) is the address you want. [or pte_val(*pte) (PAGE_SIZE-1) on x86 but this is platform-dependent.] Does this work on x86 non-kmapped highmem user pages too? (i.e. is page-virtual valid for every potential user

Re: [patch] severe softirq handling performance bug, fix, 2.4.5

2001-05-27 Thread Ingo Molnar
On Sun, 27 May 2001, Andrea Arcangeli wrote: I mean everything is fine until the same softirq is marked active again under do_softirq, in such case neither the do_softirq in do_IRQ will run it (because we are in the critical section and we hold the per-cpu locks), nor we will run it again

Re: [CHECKER] 4 security holes in 2.4.4-ac8

2001-05-29 Thread Ingo Molnar
On Tue, 29 May 2001, Dawson Engler wrote: Believe it or not, this one is OK :-) All callers pass in a pointer to a local stack kernel variable in raddr. Ah. I assumed that sys_* meant that all pointers were from user space --- is this generally not the case? (Also, are there other

Re: Reserving a (large) memory block

2000-08-31 Thread Ingo Molnar
On Thu, 31 Aug 2000, Alan Cox wrote: We then just follow the bios. You can also reserve blocks of memory by hacking arch/i386/mm/init.c and marking them reserved in 2.4 there is an explicit interface for this that also guarantees that the allocation consists of fully valid RAM (no matter how

[Announce] TUX alpha source code release

2000-09-01 Thread Ingo Molnar
We are pleased to announce that the TUX kernel-space HTTP-subsystem is available for download at: ftp://ftp.redhat.com/pub/redhat/tux/tux-hawaii/ WARNING: this is a developer-only, alpha release. The 1.0 'consumer' release will happen by the end of September. This release is useless to

Re: thread rant

2000-09-02 Thread Ingo Molnar
On Sat, 2 Sep 2000, Alexander Viro wrote: Why? I would say that bad thing about SysV shared memory is that it's _not_ sufficiently filesystem-thing - a special API where 'create a file on ramfs and bloody mmap() it' would be sufficient. Why bother with special sets of syscalls? what i mean

Re: thread rant

2000-09-02 Thread Ingo Molnar
On Sat, 2 Sep 2000, Alexander Viro wrote: what i mean is that i dont like the cleanup issues associated with SysV shared memory - eg. it can hang around even if all users have exited, so auto-cleanup of resources is not possible. unlink() and the last munmap()/exit() will get rid of

Re: zero-copy TCP

2000-09-03 Thread Ingo Molnar
On 2 Sep 2000, Jes Sorensen wrote: You can't DMA directly from a file cache page unless you have a network card that does scatter/gather DMA and surprise surprise, 80-90% of the cards on the market don't support this. [...] exactly. The TUX patch solves this by copying 'multi-fragment skbs'

Re: zero-copy TCP

2000-09-03 Thread Ingo Molnar
On Sat, 2 Sep 2000, Jeff V. Merkey wrote: Alan, Please. I'm in your code and there are copies all over the place. I agree you have a "fast path" for most stuff, but there's all kinds of handles lookups, linear list searching like have you ever bothered actually measuring the impact? I have.

Re: zero-copy TCP

2000-09-03 Thread Ingo Molnar
On Sat, 2 Sep 2000, Jeff V. Merkey wrote: **ALL** Netware network drivers support a scatter/gather proramming interface, whether the hardware does or not. In NetWare, the drivers get passed a fragment list in what's called an ECB (Event Control Block). It's the drivers responsiblity to

Re: zero-copy TCP

2000-09-03 Thread Ingo Molnar
On Sun, 3 Sep 2000 [EMAIL PROTECTED] wrote: If we go for a Linux-specific solution anyway, maybe one could add another send{,to,msg} flag that makes send*(2)'s buffer access non-atomic. That way, the kernel only needs to make sure the pages don't disappear, but there's no need for expensive

Re: zero-copy TCP

2000-09-03 Thread Ingo Molnar
On Sun, 3 Sep 2000, Andi Kleen wrote: I did the same for fragment RX some months ago (simple fragment lists that were copy-checksummed to user space). Overall it is probably better to use a kiovec, because that can be more easily used in nfsd and sendfile. the basic fragment type

Re: zero-copy TCP

2000-09-03 Thread Ingo Molnar
On 3 Sep 2000, Jes Sorensen wrote: At CERN we had a bunch of applications where this would be a win, data aquisition servers taking data in from on some custom hardware and sending out data over the wire on another card. You never really want to touch data in memory with the CPU but because

Re: zero-copy TCP

2000-09-03 Thread Ingo Molnar
On Sun, 3 Sep 2000, Andi Kleen wrote: You can already cause incorrect checksums on the wire just by passing a partly unmapped address (the zero-the-rest exception handler in csum_copy_generic in i386 forgets to add in the carry) I do not believe it is a big deal, packets with bad checksum

Re: zero-copy TCP

2000-09-05 Thread Ingo Molnar
On Tue, 5 Sep 2000, Jeff V. Merkey wrote: while (x) { x = x-next } all over the place that increases latency. [...] i challenge you to show one such place in the 2.4.0-test8-pre2 kernel. If it's all over the place and if it increases latency, you certainly can show

Re: zero-copy TCP

2000-09-05 Thread Ingo Molnar
On Tue, 5 Sep 2000, Jeff V. Merkey wrote: Alright Ingo, you asked for it. I am going through it now and going over ALL my notes. I will catalog ALL of them and post it. Is this what you really want? yes, this would be the best indeed, to get those places fixed. But if you dont want to spend

Re: zero-copy TCP

2000-09-05 Thread Ingo Molnar
btw., - the maintainers of the 2.4 networking and TCP/IP code are Alexey Kuznetsov and David S. Miller - please direct your findings towards them, not me :-) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED]

Re: zero-copy TCP

2000-09-05 Thread Ingo Molnar
On Tue, 5 Sep 2000, Jeff V. Merkey wrote: The origin of this comment was related to a comparison of the MSM/TSM/CSM layer in NetWare and Linux. I've already said that Alan's code handles fast paths well and from what I've seen is comparable to NetWare. [...] can we thus take this as a

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

2000-09-05 Thread Ingo Molnar
On Tue, 5 Sep 2000, Jeff V. Merkey wrote: Jes Sorensen wrote: HAve you contributed code to anything but your own private project which you have just declared to be withdrawn so you can go stick it into your own custom OS? I don't remember seeing you contribute code to any other part

Re: zero-copy TCP

2000-09-05 Thread Ingo Molnar
On Wed, 6 Sep 2000, Chris Wedgwood wrote: [...] The point is that a write() is only used if some sort of dynamic data is generated on the fly. There are exsiting applications out there that use mmap+write (caching the maps), it would be nice for the authors of these not to have

Re: Clearing of Ram?

2000-09-06 Thread Ingo Molnar
On Wed, 6 Sep 2000, Frank Peters wrote: My question is who cleared it the kernel or the malloc function in glibc?? (i found some code in glibc but nothing in kernel) thx it's the second clear_user_highpage() in mm/memory.c that does the page clearing in the typical malloc()-ed memory case.

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

2000-09-06 Thread Ingo Molnar
On Wed, 6 Sep 2000, J. Dow wrote: If the Kernel Debugger creates faulty solutions through lack of thinking, and asking why, then surely printk is at least as bad because it allows somebody to view the operation of the kernel through a keyhole darkly. [...] i'd like to quote David here,

Re: Availability of kdb

2000-09-07 Thread Ingo Molnar
On Wed, 6 Sep 2000, Jeff V. Merkey wrote: [...] Hardware problems require a debugger or logic analyzer to fix. [...] 'kernel problems need a kernel debugger to fix'. How wrong. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message

Re: Availability of kdb

2000-09-07 Thread Ingo Molnar
On Thu, 7 Sep 2000, Jeff V. Merkey wrote: [...] Hardware problems require a debugger or logic analyzer to fix. [...] 'kernel problems need a kernel debugger to fix'. How wrong. It says "hardware problems" not "kernel problems". read it again. translation of my sentence: "you

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

2000-09-05 Thread Ingo Molnar
On Tue, 5 Sep 2000, Alan Cox wrote: I spend my time thinking. But I prefer to spend it thinking about the bug not about finding it and how long fsck takes. [...] if we only optimize for the debugging time spent by seasoned kernel developers then you are completely right. But if we optimize

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

2000-09-05 Thread Ingo Molnar
On Tue, 5 Sep 2000, Jeff V. Merkey wrote: Your arguments are personal, not technical. [...] no, my arguments are technical, but are simply focused towards the conceptual (horizontal) development of Linux, not the vertical development of Linux (drivers) and support issues. Ingo - To

Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

2000-09-05 Thread Ingo Molnar
On Tue, 5 Sep 2000, Jeff V. Merkey wrote: A kernel debugger will reduce development costs. [...] ... of Jeff V. Merkey - possibly. You are too much focused on your own needs, you dont contribute a bit to the generic kernel and the kernel infrastructure itself. Ingo - To unsubscribe

Re: Terrible elevator performance in kernel 2.4.0-test8

2000-09-14 Thread Ingo Molnar
i'm seeing similar problems. I think these problems started when the elevator was rewritten, i believe it broke the proper unplugging of IO devices. Does your performance problem get fixed by the attached workaround? Ingo On Thu, 14 Sep 2000, Robert Cohen wrote: For a while, Ive been

Re: [PATCH] old+new RAID for 2.2.17+

2000-09-22 Thread Ingo Molnar
i strongly disagree. It's a nightmare to have three variants of the same code at once. (mdtools, raidtools and raidtools2.) This mess has been cleaned up in 2.4, and we shouldnt touch 2.2's RAID code beyond bugfixes. This is not support for 'old hardware', it's support for the very same thing.

  1   2   3   4   5   6   7   8   9   10   >