This reverts commit 9b85a95.
the reason of the additional averaging was to evaluate the runqueue for the total sampling interval instead of single sampling window. However, some peole reported lagginess and I suspect it may be related with this one. so, let's try to disable it and see if it helps. + some additional changes to make the governor more responsive.
…oot into download mode
…ing on the rom type.
…events other cores kicking in because of the modified freq table
…po for s2 and build script + tiny fix in tmu for s2
…ses (to toggle mdnie negative effect) static variables to be able to configure them with kmemhelper
…n inline" fixes for linaro toolchain compatibility" This reverts commit 8ffe1d0.
…" fixes for linaro toolchain compatibility
It improves perfomance, especially if autogroup is enabled. The size of set_task_rq() was 0x180 and now it is 0xa0. Signed-off-by: Andrew Vagin <email@example.com> Acked-by: Paul Turner <firstname.lastname@example.org> Signed-off-by: Peter Zijlstra <email@example.com> Link: http://firstname.lastname@example.org Signed-off-by: Ingo Molnar <email@example.com>
This is the easiest way to bypass module_layout check to be able to load proprietery exfat modules without making any change on them.
Hi, Jens, If you recall, I posted an RFC patch for this back in July of last year: http://lkml.org/lkml/2010/7/13/279 The basic problem is that a process can issue a never-ending stream of async direct I/Os to the same sector on a device, thus starving out other I/O in the system (due to the way the alias handling works in both cfq and deadline). The solution I proposed back then was to start dispatching from the fifo after a certain number of aliases had been dispatched. Vivek asked why we had to treat aliases differently at all, and I never had a good answer. So, I put together a simple patch which allows aliases to be added to the rb tree (it adds them to the right, though that doesn't matter as the order isn't guaranteed anyway). I think this is the preferred solution, as it doesn't break up time slices in CFQ or batches in deadline. I've tested it, and it does solve the starvation issue. Let me know what you think. Cheers, Jeff Signed-off-by: Jeff Moyer <firstname.lastname@example.org> Signed-off-by: Jens Axboe <email@example.com>
… atomic functions) by CodeAurora
Include <linux/cryptohash.h> to pickup the declarations for sha_transform and sha_init to quite the sparse noise: warning: symbol 'sha_transform' was not declared. Should it be static? warning: symbol 'sha_init' was not declared. Should it be static? Signed-off-by: H Hartley Sweeten <firstname.lastname@example.org> Acked-by: Mandeep Singh Baines <email@example.com> Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
Since commit 1eb19a12bd22 ("lib/sha1: use the git implementation of SHA-1"), the ARM SHA1 routines no longer work. The reason? They depended on the larger 320-byte workspace, and now the sha1 workspace is just 16 words (64 bytes). So the assembly version would overwrite the stack randomly. The optimized asm version is also probably slower than the new improved C version, so there's no reason to keep it around. At least that was the case in git, where what appears to be the same assembly language version was removed two years ago because the optimized C BLK_SHA1 code was faster. Reported-and-tested-by: Joachim Eastwood <email@example.com> Cc: Andreas Schwab <firstname.lastname@example.org> Cc: Nicolas Pitre <email@example.com> Signed-off-by: Linus Torvalds <firstname.lastname@example.org>
For ChromiumOS, we use SHA-1 to verify the integrity of the root filesystem. The speed of the kernel sha-1 implementation has a major impact on our boot performance. To improve boot performance, we investigated using the heavily optimized sha-1 implementation used in git. With the git sha-1 implementation, we see a 11.7% improvement in boot time. 10 reboots, remove slowest/fastest. Before: Mean: 6.58 seconds Stdev: 0.14 After (with git sha-1, this patch): Mean: 5.89 seconds Stdev: 0.07 The other cool thing about the git SHA-1 implementation is that it only needs 64 bytes of stack for the workspace while the original kernel implementation needed 320 bytes. Signed-off-by: Mandeep Singh Baines <email@example.com> Cc: Ramsay Jones <firstname.lastname@example.org> Cc: Nicolas Pitre <email@example.com> Cc: Herbert Xu <firstname.lastname@example.org> Cc: David S. Miller <email@example.com> Cc: firstname.lastname@example.org Signed-off-by: Linus Torvalds <email@example.com>
…n the selected governor.
…bug later if we need these debug messages