ures.
The code should support the use of KMALLOC_MIN_SIZE, but I have no hardware to
test this on.
compiled with gcc 4.7.2
patch against 3.6
Signed-off-by: Richard Kennedy
---
include/linux/slub_def.h | 95 +--
mm/slub.c|
Use the always inlined function kmalloc_index to translate
sizes to indexes, so that we don't have to have the slab indexes
hard coded in two places.
Signed-off-by: Richard Kennedy
---
mm/slub.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/slub.c b/mm
rk after the kmalloc_cache
array get reordered.
The second patch adds the new slabs, updates the kmalloc code and
kmem_cache_init().
This version is a drop in replacement for the existing code, but I could make
it a config option if
you prefer.
regards
Richard
Richard Kennedy (2):
SLUB: remove ha
array get reordered.
The second patch adds the new slabs, updates the kmalloc code and
kmem_cache_init().
This version is a drop in replacement for the existing code, but I could make
it a config option if
you prefer.
regards
Richard
Richard Kennedy (2):
SLUB: remove hard coded magic
Use the always inlined function kmalloc_index to translate
sizes to indexes, so that we don't have to have the slab indexes
hard coded in two places.
Signed-off-by: Richard Kennedy rich...@rsk.demon.co.uk
---
mm/slub.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff
.
The code should support the use of KMALLOC_MIN_SIZE, but I have no hardware to
test this on.
compiled with gcc 4.7.2
patch against 3.6
Signed-off-by: Richard Kennedy rich...@rsk.demon.co.uk
---
include/linux/slub_def.h | 95 +--
mm/slub.c| 162
Hi all,
If I run
perf bench --format=simple all > test.out
I get this line repeated hundreds of times in test.out
# Running sched/messaging benchmark...
interleaved with the useful output.
It's only printed once if I call it from the command line, it just
redirecting to a file
Hi all,
If I run
perf bench --format=simple all test.out
I get this line repeated hundreds of times in test.out
# Running sched/messaging benchmark...
interleaved with the useful output.
It's only printed once if I call it from the command line, it just
redirecting to a file
On 19/09/12 15:59, Jeff Moyer wrote:
> Jeff Moyer writes:
>
>> Hi,
>>
>> When testing against a pcie ssd or a ramdisk, making the block device
>> structure cacheline_aligned provided a significant increase in
>> performance:
>
> Self-NACK on this one. This results in a ton of warnings:
>
>
On 19/09/12 15:59, Jeff Moyer wrote:
Jeff Moyer jmo...@redhat.com writes:
Hi,
When testing against a pcie ssd or a ramdisk, making the block device
structure cacheline_aligned provided a significant increase in
performance:
Self-NACK on this one. This results in a ton of warnings:
for more padding.
Signed-off-by: Richard Kennedy
---
patch against v3.5-rc6
compiled and tested on x86_64
I've been running this patch for several weeks with no obvious problems.
This will allow the usb_host_interface array to be a bit smaller and should
better align with the cachelines.
regards
for more padding.
Signed-off-by: Richard Kennedy rich...@rsk.demon.co.uk
---
patch against v3.5-rc6
compiled and tested on x86_64
I've been running this patch for several weeks with no obvious problems.
This will allow the usb_host_interface array to be a bit smaller and should
better align
On Fri, 2008-02-15 at 14:46 -0800, Randy Dunlap wrote:
> On Fri, 15 Feb 2008 17:42:24 +0000 Richard Kennedy wrote:
>
> >
> > On Fri, 2008-02-15 at 09:21 -0800, Randy Dunlap wrote:
> > > On Fri, 15 Feb 2008 17:13:12 + Richard Kennedy wrote:
> > >
>
On Fri, 2008-02-15 at 14:46 -0800, Randy Dunlap wrote:
On Fri, 15 Feb 2008 17:42:24 + Richard Kennedy wrote:
On Fri, 2008-02-15 at 09:21 -0800, Randy Dunlap wrote:
On Fri, 15 Feb 2008 17:13:12 + Richard Kennedy wrote:
When running make htmldocs I'm seeing some non-fatal
On Fri, 2008-02-15 at 09:44 -0800, Randy Dunlap wrote:
> On Fri, 15 Feb 2008 09:21:54 -0800 Randy Dunlap wrote:
>
> > On Fri, 15 Feb 2008 17:13:12 +0000 Richard Kennedy wrote:
> >
> > > When running "make htmldocs" I'm seeing some non-fatal perl e
On Fri, 2008-02-15 at 09:21 -0800, Randy Dunlap wrote:
> On Fri, 15 Feb 2008 17:13:12 +0000 Richard Kennedy wrote:
>
> > When running "make htmldocs" I'm seeing some non-fatal perl errors
> > caused by trying to parse the callback function definitions in
> > bl
When running "make htmldocs" I'm seeing some non-fatal perl errors
caused by trying to parse the callback function definitions in
blk-core.c.
The errors are "Use of uninitialized value in concatenation (.)..."
The function pointers are defined without a * i.e.
int (drv_callback)(struct request
On Fri, 2008-02-15 at 09:21 -0800, Randy Dunlap wrote:
On Fri, 15 Feb 2008 17:13:12 + Richard Kennedy wrote:
When running make htmldocs I'm seeing some non-fatal perl errors
caused by trying to parse the callback function definitions in
blk-core.c.
Hi Richard,
Thanks
When running make htmldocs I'm seeing some non-fatal perl errors
caused by trying to parse the callback function definitions in
blk-core.c.
The errors are Use of uninitialized value in concatenation (.)...
The function pointers are defined without a * i.e.
int (drv_callback)(struct request *)
On Fri, 2008-02-15 at 09:44 -0800, Randy Dunlap wrote:
On Fri, 15 Feb 2008 09:21:54 -0800 Randy Dunlap wrote:
On Fri, 15 Feb 2008 17:13:12 + Richard Kennedy wrote:
When running make htmldocs I'm seeing some non-fatal perl errors
caused by trying to parse the callback function
Mike Frysinger wrote:
> On Jan 28, 2008 5:40 AM, Bryan Wu <[EMAIL PROTECTED]> wrote:
>> On Mon, 2008-01-28 at 05:16 -0500, Mike Frysinger wrote:
>>> the trouble is that this file currently weighs in at ~1.8 megs. this
>>> is because it contains all the information for all Blackfin processors
>>>
Mike Frysinger wrote:
On Jan 28, 2008 5:40 AM, Bryan Wu [EMAIL PROTECTED] wrote:
On Mon, 2008-01-28 at 05:16 -0500, Mike Frysinger wrote:
the trouble is that this file currently weighs in at ~1.8 megs. this
is because it contains all the information for all Blackfin processors
we support
On Thu, 2008-01-24 at 22:23 +0100, Sam Ravnborg wrote:
> On Mon, Jan 21, 2008 at 12:02:13PM +0000, Richard Kennedy wrote:
> > config option to add the git branch name to the automatically generated
> > version string.
> >
> > If the current git branch name is not
On Thu, 2008-01-24 at 22:23 +0100, Sam Ravnborg wrote:
On Mon, Jan 21, 2008 at 12:02:13PM +, Richard Kennedy wrote:
config option to add the git branch name to the automatically generated
version string.
If the current git branch name is not master then add the name
config option to add the git branch name to the automatically generated
version string.
If the current git branch name is not "master" then add the name to the
LOCALVERSION_AUTO version string.
The format will then be --g
Signed-off-by: Richard Kennedy <[EMAIL PROTECTED]&g
config option to add the git branch name to the automatically generated
version string.
If the current git branch name is not master then add the name to the
LOCALVERSION_AUTO version string.
The format will then be -name-g
Signed-off-by: Richard Kennedy [EMAIL PROTECTED]
---
Makefile
Here's a couple of small additions to BUG-HUNTING.
1. point out that you can list code in gdb with only one command
(gdb) l *( + offset)
2. give a very brief hint how to decode module symbols in call traces
Signed-off-by: Richard Kennedy <[EMAIL PROTECTED]>
It would have sa
Here's a couple of small additions to BUG-HUNTING.
1. point out that you can list code in gdb with only one command
(gdb) l *(symbol + offset)
2. give a very brief hint how to decode module symbols in call traces
Signed-off-by: Richard Kennedy [EMAIL PROTECTED]
It would have
On Sat, 2007-12-22 at 02:06 -0800, Andrew Morton wrote:
> On Mon, 17 Dec 2007 12:13:22 + richard <[EMAIL PROTECTED]> wrote:
>
> > fix lockup in when calling drop_caches
> >
> > calling /proc/sys/vm/drop_caches can hang due to a AB/BA lock dependency
> > between j_list_lock
On Sat, 2007-12-22 at 02:06 -0800, Andrew Morton wrote:
On Mon, 17 Dec 2007 12:13:22 + richard [EMAIL PROTECTED] wrote:
fix lockup in when calling drop_caches
calling /proc/sys/vm/drop_caches can hang due to a AB/BA lock dependency
between j_list_lock and the
On Tue, 2007-10-23 at 16:03 +0200, Peter Zijlstra wrote:
> On Tue, 2007-10-23 at 14:55 +0100, richard kennedy wrote:
> > on git v2.6.23-6636-g557ebb7 I'm getting a soft lockup when running a
> > simple disk write test case on AMD64X2, sata hd & ext3.
> >
> > the t
on git v2.6.23-6636-g557ebb7 I'm getting a soft lockup when running a
simple disk write test case on AMD64X2, sata hd & ext3.
the test does this
sync
echo 3 > /proc/sys/vm/drop_caches
for (( i=0; $i < $count; i=$i+1 )) ; do
dd if=large_file of=copy_file_$i bs=4k &
done
It never recovers once
on git v2.6.23-6636-g557ebb7 I'm getting a soft lockup when running a
simple disk write test case on AMD64X2, sata hd ext3.
the test does this
sync
echo 3 /proc/sys/vm/drop_caches
for (( i=0; $i $count; i=$i+1 )) ; do
dd if=large_file of=copy_file_$i bs=4k
done
It never recovers once the
On Tue, 2007-10-23 at 16:03 +0200, Peter Zijlstra wrote:
On Tue, 2007-10-23 at 14:55 +0100, richard kennedy wrote:
on git v2.6.23-6636-g557ebb7 I'm getting a soft lockup when running a
simple disk write test case on AMD64X2, sata hd ext3.
the test does this
sync
echo 3 /proc/sys
When background_writeout() (mm/page-writeback.c) finds any pages_skipped
in writeback_inodes() and it didn't meet any congestion, it exits even
when it hasn't written enough pages yet.
Performing 2 ( or more) concurrent copies of a large file, often creates
lots of skipped pages (1000+) making
When background_writeout() (mm/page-writeback.c) finds any pages_skipped
in writeback_inodes() and it didn't meet any congestion, it exits even
when it hasn't written enough pages yet.
Performing 2 ( or more) concurrent copies of a large file, often creates
lots of skipped pages (1000+) making
On Tue, 2007-10-02 at 10:00 +0800, Fengguang Wu wrote:
> On Mon, Oct 01, 2007 at 11:57:34AM -0400, Chuck Ebbert wrote:
> > On 09/29/2007 07:04 AM, Fengguang Wu wrote:
...
>
> (expecting real world confirmations...)
>
> Here is a new safer version. It's more ugly though.
>
> ---
> writeback:
On Tue, 2007-10-02 at 10:00 +0800, Fengguang Wu wrote:
On Mon, Oct 01, 2007 at 11:57:34AM -0400, Chuck Ebbert wrote:
On 09/29/2007 07:04 AM, Fengguang Wu wrote:
...
(expecting real world confirmations...)
Here is a new safer version. It's more ugly though.
---
writeback: avoid
I enabled config_jbd_debug in the hope that it may help track down the
lockup I'm seeing, but unfortunately the /proc entry does not get
created.
any ideas how to fix this ?
My machine is an Athlon 64X2 - fedora 7 x86_64 - 2.6.23-rc7
CONFIG_EXT3_FS=m
CONFIG_JBD=m
CONFIG_JBD_DEBUG=y
I added the
I enabled config_jbd_debug in the hope that it may help track down the
lockup I'm seeing, but unfortunately the /proc entry does not get
created.
any ideas how to fix this ?
My machine is an Athlon 64X2 - fedora 7 x86_64 - 2.6.23-rc7
CONFIG_EXT3_FS=m
CONFIG_JBD=m
CONFIG_JBD_DEBUG=y
I added the
On Fri, 2007-09-21 at 03:33 -0700, Andrew Morton wrote:
> On Fri, 21 Sep 2007 11:25:41 +0100 richard kennedy <[EMAIL PROTECTED]> wrote:
>
> > > That's all a bit crappy if the wrong races happen and some other task is
> > > somehow exceeding the dirty limits each tim
On Fri, 2007-09-21 at 03:33 -0700, Andrew Morton wrote:
On Fri, 21 Sep 2007 11:25:41 +0100 richard kennedy [EMAIL PROTECTED] wrote:
That's all a bit crappy if the wrong races happen and some other task is
somehow exceeding the dirty limits each time this task polls them. Seems
On Fri, 2007-09-21 at 03:33 -0700, Andrew Morton wrote:
> On Fri, 21 Sep 2007 11:25:41 +0100 richard kennedy <[EMAIL PROTECTED]> wrote:
>
> > > That's all a bit crappy if the wrong races happen and some other task is
> > > somehow exceeding the dirty limits each tim
On Thu, 2007-09-20 at 15:36 -0700, Andrew Morton wrote:
> On Thu, 20 Sep 2007 18:04:38 -0400
> Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> > >
> > >> Can we get some kind of band-aid, like making the endless 'for' loop in
> > >> balance_dirty_pages() terminate after some number of iterations?
On Thu, 2007-09-20 at 15:36 -0700, Andrew Morton wrote:
On Thu, 20 Sep 2007 18:04:38 -0400
Chuck Ebbert [EMAIL PROTECTED] wrote:
Can we get some kind of band-aid, like making the endless 'for' loop in
balance_dirty_pages() terminate after some number of iterations? Clearly
if we
On Fri, 2007-09-21 at 03:33 -0700, Andrew Morton wrote:
On Fri, 21 Sep 2007 11:25:41 +0100 richard kennedy [EMAIL PROTECTED] wrote:
That's all a bit crappy if the wrong races happen and some other task is
somehow exceeding the dirty limits each time this task polls them. Seems
On Tue, 2007-08-21 at 16:36 -0700, Andrew Morton wrote:
> On Sun, 19 Aug 2007 15:56:07 + (UTC)
> richard kennedy <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 09 Aug 2007 22:42:54 -0700, Andrew Morton wrote:
> >
> > > ftp://ftp.kernel.org/pub/linux/kernel/peo
On Tue, 2007-08-21 at 16:36 -0700, Andrew Morton wrote:
On Sun, 19 Aug 2007 15:56:07 + (UTC)
richard kennedy [EMAIL PROTECTED] wrote:
On Thu, 09 Aug 2007 22:42:54 -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-
rc2/2.6.23-rc2-mm2
On Thu, 09 Aug 2007 22:42:54 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-
rc2/2.6.23-rc2-mm2/
>
> - Various problems from 2.6.23-rc2-mm1 were fixed
>
>
>
> Boilerplate:
>
> - See the `hot-fixes' directory for any important updates to
On Thu, 09 Aug 2007 22:42:54 -0700, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-
rc2/2.6.23-rc2-mm2/
- Various problems from 2.6.23-rc2-mm1 were fixed
Boilerplate:
- See the `hot-fixes' directory for any important updates to this
On Fri, 2007-08-03 at 14:37 +0200, Peter Zijlstra wrote:
> Per device dirty throttling patches
>
> These patches aim to improve balance_dirty_pages() and directly address three
> issues:
> 1) inter device starvation
> 2) stacked device deadlocks
> 3) inter process starvation
Hi Peter,
I've
On Fri, 2007-08-03 at 14:37 +0200, Peter Zijlstra wrote:
Per device dirty throttling patches
These patches aim to improve balance_dirty_pages() and directly address three
issues:
1) inter device starvation
2) stacked device deadlocks
3) inter process starvation
snip
Hi Peter,
I've
On Wed, 01 Aug 2007 18:39:51 -0400, Chuck Ebbert wrote:
> Looks like the same problem with spinlock unfairness we've seen
> elsewhere: it seems to be looping here? Or is everyone stuck just
> waiting for writeout?
>
> lock_timer_base():
> for (;;) {
> tvec_base_t
On Wed, 01 Aug 2007 18:39:51 -0400, Chuck Ebbert wrote:
Looks like the same problem with spinlock unfairness we've seen
elsewhere: it seems to be looping here? Or is everyone stuck just
waiting for writeout?
lock_timer_base():
for (;;) {
tvec_base_t *prelock_base =
e a version of this
patch that includes a printk and a test case that occasionally does
trigger this condition.
Signed-off-by: Richard Kennedy <[EMAIL PROTECTED]>
--
--- linux-2.6.22.1/mm/page-writeback.c.orig 2007-07-30 16:36:09.0
+0100
+++ linux-2.6.22.1/mm/page-writeback
of this
patch that includes a printk and a test case that occasionally does
trigger this condition.
Signed-off-by: Richard Kennedy [EMAIL PROTECTED]
--
--- linux-2.6.22.1/mm/page-writeback.c.orig 2007-07-30 16:36:09.0
+0100
+++ linux-2.6.22.1/mm/page-writeback.c 2007-07-31 16:26
On Fri, 2007-05-04 at 23:32 +0900, Komuro wrote:
> On Thu, 03 May 2007 15:29:19 +0100
> Richard Kennedy <[EMAIL PROTECTED]> wrote:
>
>
> IDE bugs should be posted to the linux-ide mailing list.
>
>
> > Hi all,
> > I have a JVC MP-CDX1 cdrom dr
On Fri, 2007-05-04 at 23:32 +0900, Komuro wrote:
On Thu, 03 May 2007 15:29:19 +0100
Richard Kennedy [EMAIL PROTECTED] wrote:
IDE bugs should be posted to the linux-ide mailing list.
Hi all,
I have a JVC MP-CDX1 cdrom drive that came with my laptop which used to
work with ide-cs
Hi,
FWIW the following routine is consistently slightly faster using
Steven's test harness , with a big win when no bit set.
static inline int new_find_first_bit(const unsigned long *b, unsigned
size)
{
int x = 0;
do {
unsigned long v = *b++;
if (v)
Hi,
FWIW the following routine is consistently slightly faster using
Steven's test harness , with a big win when no bit set.
static inline int new_find_first_bit(const unsigned long *b, unsigned
size)
{
int x = 0;
do {
unsigned long v = *b++;
if (v)
60 matches
Mail list logo
