- 16 Jul, 2007 40 commits
-
-
Badari Pulavarty authored
This is a patch that speeds up statfs. It is very simple - the "overhead" calculation, which takes a huge amount of time for large filesystems, never changes unless the size of the filesystem itself changes. That means we can store it in memory and only recalculate if the filesystem has been resized (almost never). It also fixes a minor problem that we never update the on-disk superblock free blocks/inodes counts until the filesystem is unmounted. While not fatal, we may as well update that on disk when we have the information, and it makes things like debugfs and dumpe2fs report a bit more accurate info. Signed-off-by:
Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by:
Andreas Dilger <adilger@clusterfs.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Badari Pulavarty authored
This is a patch that speeds up statfs. It is very simple - the "overhead" calculation, which takes a huge amount of time for large filesystems, never changes unless the size of the filesystem itself changes. That means we can store it in memory and only recalculate if the filesystem has been resized (almost never). It also fixes a minor problem that we never update the on-disk superblock free blocks/inodes counts until the filesystem is unmounted. While not fatal, we may as well update that on disk when we have the information, and it makes things like debugfs and dumpe2fs report a bit more accurate info. Signed-off-by:
-
Badari Pulavarty authored
This is a patch that speeds up statfs. It is very simple - the "overhead" calculation, which takes a huge amount of time for large filesystems, never changes unless the size of the filesystem itself changes. That means we can store it in memory and only recalculate if the filesystem has been resized (almost never). It also fixes a minor problem that we never update the on-disk superblock free blocks/inodes counts until the filesystem is unmounted. While not fatal, we may as well update that on disk when we have the information, and it makes things like debugfs and dumpe2fs report a bit more accurate info. Signed-off-by:
-
Dan Aloni authored
Signed-off-by:
Dan Aloni <da-x@monatomic.org> Signed-off-by:
-
Dan Aloni authored
Signed-off-by:
-
Denis Vlasenko authored
Optimize integer-to-string conversion in vsprintf.c for base 10. This is by far the most used conversion, and in some use cases it impacts performance. For example, top reads /proc/$PID/stat for every process, and with 4000 processes decimal conversion alone takes noticeable time. Using code from http://www.cs.uiowa.edu/~jones/bcd/decimal.html (with permission from the author, Douglas W. Jones) binary-to-decimal-string conversion is done in groups of five digits at once, using only additions/subtractions/shifts (with -O2; -Os throws in some multiply instructions). On i386 arch gcc 4.1.2 -O2 generates ~500 bytes of code. This patch is run tested. Userspace benchmark/test is also attached. I tested it on PIII and AMD64 and new code is generally ~2.5 times faster. On AMD64: # ./vsprintf_verify-O2 Original decimal conv: .......... 151 ns per iteration Patched decimal conv: .......... 62 ns per iteration Testing correctness 12895992590592 ok... [Ctrl-C] # ./vsprintf_verify-O2 Original decimal conv: .......... 151 ns per iteration Patched decimal conv: .......... 62 ns per iteration Testing correctness 26025406464 ok... [Ctrl-C] More realistic test: top from busybox project was modified to report how many us it took to scan /proc (this does not account any processing done after that, like sorting process list), and then I test it with 4000 processes: #!/bin/sh i=4000 while test $i != 0; do sleep 30 & let i-- done busybox top -b -n3 >/dev/null on unpatched kernel: top: 4120 processes took 102864 microseconds to scan top: 4120 processes took 91757 microseconds to scan top: 4120 processes took 92517 microseconds to scan top: 4120 processes took 92581 microseconds to scan on patched kernel: top: 4120 processes took 75460 microseconds to scan top: 4120 processes took 66451 microseconds to scan top: 4120 processes took 67267 microseconds to scan top: 4120 processes took 67618 microseconds to scan The speedup comes from much faster generation of /proc/PID/stat by sprintf() calls inside the kernel. Signed-off-by:
Douglas W Jones <jones@cs.uiowa.edu> Signed-off-by:
Denys Vlasenko <vda.linux@googlemail.com> Signed-off-by:
-
Denis Vlasenko authored
* There is no point in having full "0...9a...z" constant vector, if we use only "0...9a...f" (and "x" for "0x"). * Post-decrement usually needs a few more instructions, so use pre decrement instead where makes sense: - while (i < precision--) { + while (i <= --precision) { * if base != 10 (=> base 8 or 16), we can avoid using division in a loop and use mask/shift, obtaining much faster conversion. (More complex optimization for base 10 case is in the second patch). Overall, size vsprintf.o shows ~80 bytes smaller text section with this patch applied. Signed-off-by: -
J. Bruce Fields authored
Trivial typo and grammar fixes. Signed-off-by:
"J. Bruce Fields" <bfields@citi.umich.edu> Cc: Davide Libenzi <davidel@xmailserver.org> Signed-off-by:
-
Jesper Juhl authored
In drivers/pnp/isapnp/core.c::isapnp_read_tag() there is a test of 'type' being == 0 a bit down in the function. That test doesn't make any sense. If 'type' could indeed be NULL, then the test happens way too late as we'd already have tried to dereference the pointer earlier and looking at the callers it also turns out that there is no way type can ever actually be NULL. So the test is completely pointless and should just be removed. Signed-off-by:
Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by:
-
Alexey Dobriyan authored
headers_install by default puts headers into usr/include/ . They're auto-generated, so should be ignored. Same for *.orig, *.rej . Signed-off-by:
Alexey Dobriyan <adobriyan@sw.ru> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Adrian Bunk authored
congestion_wait_interruptible() is no longer used. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Acked-by:
Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by:
-
Jiri Kosina authored
kernel/printk.c: document possible deadlock against scheduler The printk's comment states that it can be called from every context, which might lead to false illusion that it could be called from everywhere without any restrictions. This is however not true - a call to printk() could deadlock if called from scheduler code (namely from schedule(), wake_up(), etc) on runqueue lock when it tries to wake up klogd. Document this. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Ed L. Cashin authored
Static initialization of spinlocks is preferable to dynamic initialization when it is practical. This patch updates documentation for consistency with comments in spinlock_types.h. Signed-off-by:
Ed L. Cashin <ecashin@coraid.com> Signed-off-by:
-
Alan Cox authored
Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Alan Cox authored
Remove the broken 'no termios change' optimisation for this driver. Signed-off-by:
-
Alan Cox authored
Again this check is wrong now, and un-needed Signed-off-by:
-
Alan Cox authored
We've been using the 'new locking' for a long time now so it seems pointless keeping the old one around. Remove it and undo the macros it uses back into real code for readability. Remove the bogus 'no termios change' checks. Signed-off-by:
-
Alan Cox authored
Lots of serial drivers check and optimise for setting the termios values to the ones they were before. This is pointless and the check is wrong anyway. Remove the checks on the serial drivers. If we ever do need such a check put it back in the tty layer instead _once_! Signed-off-by:
-
Rusty Russell authored
Now we always use stop_machine for module insertion or deletion, we no longer need the modlist_lock: merely disabling preemption is sufficient to block against list manipulation. This avoids deadlock on OOPSen where we can potentially grab the lock twice. Bug: 8695 Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Cc: Ingo Molnar <mingo@elte.hu> Cc: Tobias Oed <tobiasoed@hotmail.com> Signed-off-by:
-
Borislav Petkov authored
Fix error handling in ext4_create_journal according to kernel conventions. Signed-off-by:
Borislav Petkov <bbpetkov@yahoo.de> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Borislav Petkov authored
Fix error handling in ext3_create_journal according to kernel conventions. Signed-off-by:
-
Oleg Nesterov authored
Change cancel_work_sync() and cancel_delayed_work_sync() to return a boolean indicating whether the work was actually cancelled. A zero return value means that the work was not pending/queued. Without that kind of change it is not possible to avoid flush_workqueue() sometimes, see the next patch as an example. Also, this patch unifies both functions and kills the (unlikely) busy-wait loop. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Acked-by:
Jarek Poplawski <jarkao2@o2.pl> Signed-off-by:
-
Oleg Nesterov authored
Imho, the current naming of cancel_xxx workqueue functions is very confusing. cancel_delayed_work() cancel_rearming_delayed_work() cancel_rearming_delayed_workqueue() // obsolete cancel_work_sync() This looks as if the first 2 functions differ in "type" of their argument which is not true any longer, nowadays the difference is the behaviour. The semantics of cancel_rearming_delayed_work(dwork) was changed significantly, it doesn't require that dwork rearms itself, and cancels dwork synchronously. Rename it to cancel_delayed_work_sync(). This matches cancel_delayed_work() and cancel_work_sync(). Re-create cancel_rearming_delayed_work() as a simple inline obsolete wrapper, like cancel_rearming_delayed_workqueue(). Signed-off-by:
-
Borislav Petkov authored
Update Documentation/filesystems/vfs.txt Signed-off-by:
-
Jesper Juhl authored
The UMSDOS filesystem was removed back in 2.6.11, but some tiny bits stuck around. This patch removes the few remaining leftovers. The only things left behind after this are the entries in the CREDITS file and the ioctl number in Documentation/ioctl-number.txt as documentation. This third (hopefully final) version of the patch doesn't edit the arch/um/config.release file, since Jeff Dike pointed out to me that it should die completely, and asked me to remove it from my patch as he'll send in a seperate patch removing the file completely. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Jesper Juhl authored
Add descriptions for a number of missing files and directories to the Documentation/00-INDEX file. Signed-off-by:
Rob Landley <rob@landley.net> Signed-off-by:
-
Yinghai Lu authored
Using dev_to_node(&dev->dev) to get node, and kmalloc_node to dma buffer on corresponding node dma pool Signed-off-by:
Yinghai Lu <yinghai.lu@sun.com> Cc: Andi Kleen <ak@suse.de> Cc: Christoph Lameter <clameter@sgi.com> Cc: David Rientjes <rientjes@google.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Cyrill Gorcunov authored
We have to change udf_crc16() name to udf_crc() to be able to play with CRC test. Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> Cc: Jan Kara <jack@ucw.cz> Signed-off-by:
-
Heiko Carstens authored
The current generic bug implementation has a call to dump_stack() in case a WARN_ON(whatever) gets hit. Since report_bug(), which calls dump_stack(), gets called from an exception handler we can do better: just pass the pt_regs structure to report_bug() and pass it to show_regs() in case of a warning. This will give more debug informations like register contents, etc... In addition this avoids some pointless lines that dump_stack() emits, since it includes a stack backtrace of the exception handler which is of no interest in case of a warning. E.g. on s390 the following lines are currently always present in a stack backtrace if dump_stack() gets called from report_bug(): [<000000000001517a>] show_trace+0x92/0xe8) [<0000000000015270>] show_stack+0xa0/0xd0 [<00000000000152ce>] dump_stack+0x2e/0x3c [<0000000000195450>] report_bug+0x98/0xf8 [<0000000000016cc8>] illegal_op+0x1fc/0x21c [<00000000000227d6>] sysc_return+0x0/0x10 Acked-by:
Jeremy Fitzhardinge <jeremy@goop.org> Acked-by:
Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Andi Kleen <ak@suse.de> Cc: Kyle McMartin <kyle@parisc-linux.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Dave Jones authored
Add -Werror-implicit-function-declaration This makes builds fail sooner if something is implicitly defined instead of having to wait half an hour for it to fail at the linking stage. Signed-off-by:
Dave Jones <davej@redhat.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Andrew Morton authored
This is a rather bizarre thing to have inlined in io.h. Stick it in lib/ instead. While we're there, despaghetti it a bit, and fix its off-by-one behaviour when passed a zero length. Signed-off-by:
-
Josh Triplett authored
I recently received a patch including a file that had a vim modeline, and I realized that nothing specifically proscribed that practice. Signed-off-by:
Josh Triplett <josh@freedesktop.org> Signed-off-by:
-
Josh Triplett authored
Signed-off-by:
Josh Triplett <josh@kernel.org> Signed-off-by:
-
vignesh babu authored
Replace (n & (n-1)) with is_power_of_2 Signed-off-by:
vignesh babu <vignesh.babu@wipro.com> Acked-by:
Evgeniy Dushistov <dushistov@mail.ru> Signed-off-by:
-
Niels de Vos authored
The IO port range requested by parport_pc.c:sio_ite_8872_probe is too small. The IO-ports of ttyS1 (0x2f8) will be missconfigured by the ITE-chip. The ITE starts looking for the chip a 0x2a0. An IO-portrange of 32 will not overwrite the ports of ttyS1. Therefore register 0x60 should be written with 0xe5000000, enabling the ITE and setting IO-portsize to 32 bytes. Signed-off-by:
-
vignesh babu authored
Replace (n & (n-1)) with is_power_of_2() Signed-off-by:
Stelian Pop <stelian@popies.net> Signed-off-by:
-
Andrea Arcangeli authored
This follows a suggestion from Chuck Ebbert on how to make seccomp absolutely zerocost in schedule too. The only remaining footprint of seccomp is in terms of the bzImage size that becomes a few bytes (perhaps even a few kbytes) larger, measure it if you care in the embedded. Signed-off-by:
Andrea Arcangeli <andrea@cpushare.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by:
-
Andrea Arcangeli authored
This reduces the memory footprint and it enforces that only the current task can enable seccomp on itself (this is a requirement for a strightforward [modulo preempt ;) ] TIF_NOTSC implementation). Signed-off-by:
-
Oleg Nesterov authored
sock_xmit() re-implements sigprocmask() and dequeue_signal_lock(). Signed-off-by:
Paul Clements <paul.clements@steeleye.com> Signed-off-by:
-
Oleg Nesterov authored
kcdrwd() is a kernel thread, all signals are ignored. Signed-off-by:
-
