ftp://e-mind.com/pub/linux/kernel-patches/arca-36-against-2.1.130.diff.gz
Differences between 2.1.130:
o CPU usage improved by waking up the process if the current
process is the idle one (bug discovered by me, the fix should be
the right pointed out by Linus).
o TCP/IP smart delayed acks feature. It _should_ improve performance
on slow links that drop packets. It can' t harm (Oops like things)
but if it decrease performance for you let me know... For major
details read my email with my patch on this list.
o My latest lp code, optimized for some new printers and merged a
lp readback patch from Tim Waugh. I am not aware if somebody
is going to add my new -T ioctl to tunelp. If somebody will
send me the tunelp sources (.tar.gz) I can do that. I am too lazy
to search download the package myself from my slow connection.
o A lot of jiffies wrap fixes.
o CTRL+SCROLL-LOCK EIP column will tell useful info. This patch
will break the compilation everywhere except Alpha and x86.
Patches for other archs are welcome ;).
o bttv will not generate 50 irq per sec. Maybe it' s not the
right thing to do, but since I only watch tv and I only grab video
I don' t need to waste CPU and L1 cache for 50 irq per sec to know
how many VSYNC are happened from time 0.
o little parport_probe anti hang patch. I don' t know if it' s the
right fix... Philip any news?
o aic7xxx_timer() change to not depend on the timer code
implementation. I consider it a cleanup, but Doug Ledford don' t
agree and told me that bugs (if I understood well). I still can' t
see where the bug is.
There' s also another bad thing in the aic7xxx driver that Doug
Ledford pointed me out: dev_last_reset[] should ne never thouched,
so it make not a lot of sense to compare dev_last_reset[] with
jiffies because jiffies could have just wrapped 2/3 times at the
time of the first scsi device reset.
I am a bit hurted by how the aic7xxx.c file is long (emacs refuse
to run the c-mode on it ;) but I am trying to find a clean way to
fix the thing. I think the trivial fix would be to add a watchdog
timer that exires every ~0>>2 jiffies and that browse all
dev_last_reset[] and set them to jiffies - ~0>>2. I also don' t
know right now if ->last_reset (a field used by the scsi
mid/high-level drivers) suffers the same jiffies wrap problem...
Setting a watchdog is not a very clean soultion but will not alter
the current code and we will not need a new field in the scsi host
struct for every TARGET...
My patch convert also a del/add_timer to a mod_timer().
o timeval/timespec/msec conversions in time.h. I hacked all
such functions and implemented the new msec_to_jiffies() to
take care of all overflow I could imagine. If you see other
overflows tell me.
o The kernel should compile fine also without sysctl. If this is
just true also with the stock kernel let me know.
o update_shared_mappings(). This my function improves a lot
performance when syncing mmaps shared between processes. All
other UNIX handle this case fine as linux + my patch.
o kswapd. My kswapd don' t depends on the jiffies duration and so on
the speed of the machine. It schedule() as a normal process and
goes to sleep when needed. I also reinserted the swap interval
sysctl because now I use __get_free_pages() to wakeup kswapd if
the system needs memory (to have not to run swap_tick every
jiffy).
o swap cache orphan pages are automagically removed from the swap
cache at exit(2) time. Probably this code is not needed and I have
not produced numbers so far. It works fine though and probably
(not sure) could help a bit in very low memory machines... I left
this code in my tree mainly because it' s more easy for me to
maintain it until I' ll have the time to do the benchmark... ;)
o little vmalloc fix
The kernel will boot at uptime = 497 days, this will allow you to catch
jiffies comparison bugs in the first hour because after one hour jiffies
will return to 0. Tell me if you' ll have problems in the first hour.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/