An error occurred fetching the project authors.
- 23 Nov, 2007 9 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
Anybody who is interested in FS performance should take a look at the latest pre-patch of 2.3.7 (only pre-6 and possibly later: do NOT get any earlier versions. pre-5 still causes file corruption, pre-6 looks good so far). Careful, though: I fixed the problem that caused some corruption less than an hour ago, and while my tests indicate it all works fine, this is a very fundamental change. The difference to earlier kernels is: - ext2 (and some other block device filesystems that have been taught about it) uses write-through from the page cache instead of having a separate buffer cache and the page cache to maintain dirty state. This means much less memory pressure in certain situations, and it also means that we can avoid unnecessary copies. - the page cache has been threaded, so on SMP you can actually get noticeable speedups from processes that do concurrent file accesses. - lower-latency read paths, especially the cached case. Both of these are big, and fundamental changes. So don't mistake me when I say it is experimental: Ingo, David and I have been spending the last weeks (especialy Ingo, who deserves a _lot_ of credit for this all: I designed much of it, but Ingo made it a reality. Thanks Ingo) on making it do the right thing and be stable, but if you worry about not having backups you might not want to play with it even so. It took us this long just to make it work reliably enough that we can't find any obvious problems.. The interesting areas are things like - writes to shared mappings now go blindingly fast. We're talking mondo cleanups here. We used to do really badly on this, now we do really well. - does bdflush still do the right thing? There may be a _lot_ of tweaking to do to get everything working at full capacity. - can people confirm that it is stable for everybody? - if anybody has 8-way machines etc, scalability is interesting. It should scale to 8-way no problem. We used to scale to 1-way, barely. Numbers? - fsync(). It doesn't work right now, but it should be easy to make it work well on big files etc - something we've never been able to do before (we used to lack the indexing from file to dirty blocks: now we have access to that quite automatically thanks to having the inode->page index in place, and the dirty blocks are right there) and I'd really appreciate comments from people, as long as people are aware that it _looks_ stable but we don't guarantee anything at this point. Linus
-
Linus Torvalds authored
..is out there, and has everybodys favourite fix, ie the version number has been bumped this time. In addition, compared to pre-1, it has: - autofs fix (uninitialized inode number could lead to "interesting" problems) - some more NFS fixes (file truncation with pending write-backs this time) - disable_irq()/enable_irq() now nests properly, as Alan convinced me (quite rightly) that they have to nest in order to work sanely with shared interrupt and multiple CPU's and various other schenarios. - more merges from Alan, we're getting closer to being synched up. Most of the bulk of the thing is the irda stuff, that most people can ignore. Linus
-
Linus Torvalds authored
The bulk of the pre-patch is just some speeling error fixes, but there's a one-liner that gets rid of the double interrupts with level-triggered irq's on the IO-APIC, and that is known to have fixed one persons SCSI tape driver (the fact that there were problems with too many interrupts implies that something is slightly buggered in the driver, but..) This should also have a ne2000 driver that doesn't get a NULL pointer fault for some people, and the irq changes should hopefully make it work on UP systems again even if the kernel is compiled as SMP. And there are some MTRR updates. Linus
-
Linus Torvalds authored
> I finnaly get the IRQ detection working with this patch, > in linux-2.1.102/arch/i386/kernel/irq.c : Ok, does it still work with 2.1.103? 2.1.103 has this patch, and also changes certain other things wrt interrupts in a way that both Edgar and Ingo seem to agree on, and it's been stable on certain boxes where plain 2.1.102 wasn't. 2.1.103 also disables the early Cyrix cpuid stuff, because we now seem to have confirmation that this is what corrupts DMA IDE transfers (the cyrix code steps on magic motherboard IO ports - which Intel probably put there specially to mess with Cyrix. But maybe I'm just cynical). So people that have had problems with disk corruption and are brave enough to try, this could be an interesting experiment. [ Thanks to Gerard Roudier and Alan Cox for chasing down the IDE corruption issue, btw ] Linus
-
Linus Torvalds authored
-
Linus Torvalds authored
This release should fix a few networking problems, and the NFS client is hopefully fairly stable even under the kinds of loads we have here at Transmeta. The 2.1.80 release also contains some initial ARM support, and contains Ingo Molnar's better SMP interrupt handling. NOTE NOTE NOTE! The new SMP interrupt handling is currently not very good at autodetection. This can be a real problem, and _before_ booting the 2.1.80 kernel as compiled for SMP you should probably try to figure out a possible IRQ override line by doing: echo -n pirq=; echo `scanpci -f | grep T_L | cut -c56-` | sed 's/ /,/g' which for me gives pirq=0x00,0x09,0x0b Then, after doing the above, boot into 2.1.80 and see if it finds your PCI interrupt lines correctly. If it does, everything is fine. If it doesn't, you need to boot with the pirq setting that you determined earlier, by giving the kernel the pirq data at the bootup command line or by using the LILO "append=" feature (or similar features in other bootloaders). We'll certainly have to make the autodetection work reliably, but in the meantime the command-line approach at least gives us a way to test the more fundamental impacts of better interrupt handling. Linus
-