2006-03-06 12:12:39

by Rui Nuno Capela

[permalink] [raw]
Subject: realtime-preempt patch-2.6.15-rt18 issues

Hi, Ingo,

I think I would let you know that I'm still on 2.6.15-rt16, which works
great for the most purposes, on all of my boxes.

My problem is that the current/latest of the realtime-preempt patch,
2.6.15-rt18, has some showstoppers, at least for my day-to-day usage.

First one, and I think this is a return of an old buglet. Its the one that
occurs every time an usb-storage device is unplugged (e.g. a usb flash
stick). Once that happens, the usb subsystem gets seriously crippled.

Here goes a sample dmesg output of this occurrence (the complete listing
is attached, as is the corresponding kernel .config).

...
usb 2-1: new full speed USB device using ohci_hcd and address 2
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
Vendor: USB 2.0 Model: Flash Disk Rev: 2.00
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 2031616 512-byte hdwr sectors (1040 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
SCSI device sda: 2031616 512-byte hdwr sectors (1040 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
sda: sda1
sd 0:0:0:0: Attached scsi removable disk sda
usb-storage: device scan complete
usb 2-1: USB disconnect, address 2
slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free all
objects
[<c0144603>] kmem_cache_destroy+0x83/0xf8 (8)
[<c020b1d6>] scsi_destroy_command_freelist+0x4e/0x5a (12)
[<c020be67>] scsi_host_dev_release+0x4e/0x71 (12)
[<c01f0fef>] device_release+0x14/0x39 (12)
[<c01a2c9b>] kobject_cleanup+0x3e/0x5e (4)
[<c01a2cbb>] kobject_release+0x0/0x8 (8)
[<e05327ac>] usb_stor_control_thread+0x0/0x183 [usb_storage] (8)
[<c01a3432>] kref_put+0x3a/0x44 (4)
[<e053290e>] usb_stor_control_thread+0x162/0x183 [usb_storage] (12)
[<c027a8a1>] schedule+0xd4/0xf5 (32)
[<c01230df>] kthread+0x63/0x8f (20)
[<c012307c>] kthread+0x0/0x8f (12)
[<c0100d59>] kernel_thread_helper+0x5/0xb (16)


The second issue seems to be related to the RTC and is not strictly
specific to -rt18. AFAICT, my experience goes far as the ALSA MIDI
sequencer is concerned (snd-seq-midi) and it badly shows whenever the RTC
timer is used (snd-rtctimer), moreover if its used by default (i.e.
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y).

As it seems specific to -rt18, the ALSA sequencer event queueing is
perfectly non-functional if the RTC timer is used. On -rt16, and probably
before, the use of snd-rtctimer is suspiciously related to some complete
and instantaneous system lockups that I was experiencing more than many
times, while doing some MIDI sequencing; it always occurred almost exactly
on queue timer stop/start instants. Once I got rid of the rtctimer,
everything seems to get back to normal, that is, no hard-freezes to date.

My current configurations tries to avoid the RTC use in any circunstance.

So I think RTC is still an open issue, and it has indeed surfaced here and
there, specially regarding the RT patch usage in the Linux Audio/MIDI
niche.

Hope I can help in anyway.

Cheers,
--
rncbc aka Rui Nuno Capela
[email protected]


Attachments:
dmesg-2.6.15.4-rt18.1.gz (5.03 kB)
config-2.6.15.4-rt18.1.gz (9.56 kB)
Download all attachments

2006-03-06 12:36:46

by Ingo Molnar

[permalink] [raw]
Subject: Re: realtime-preempt patch-2.6.15-rt18 issues


* Rui Nuno Capela <[email protected]> wrote:

> Hi, Ingo,
>
> I think I would let you know that I'm still on 2.6.15-rt16, which
> works great for the most purposes, on all of my boxes.
>
> My problem is that the current/latest of the realtime-preempt patch,
> 2.6.15-rt18, has some showstoppers, at least for my day-to-day usage.

> The second issue seems to be related to the RTC and is not strictly
> specific to -rt18. AFAICT, my experience goes far as the ALSA MIDI
> sequencer is concerned (snd-seq-midi) and it badly shows whenever the
> RTC timer is used (snd-rtctimer), moreover if its used by default
> (i.e. CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y).

does the patch below (from Karsten Wiese) solve the second problem?

Ingo

-------

> the tasklet code was reworked too to be PREEMPT_RT friendly: the new
> PI code unearthed a fundamental livelock scenario with PREEMPT_RT, and
> the fix was to rework the tasklet code to get rid of the 'retrigger
> softirqs' approach.

following patch re enables tasklet_hi. needed by ALSA MIDI.

Karsten

--- linux/kernel/softirq.c.orig
+++ linux/kernel/softirq.c
@@ -351,13 +351,13 @@
static DEFINE_PER_CPU(struct tasklet_head, tasklet_hi_vec) = { NULL };

static void inline
-__tasklet_common_schedule(struct tasklet_struct *t, struct tasklet_head *head)
+__tasklet_common_schedule(struct tasklet_struct *t, struct tasklet_head *head, unsigned int nr)
{
if (tasklet_trylock(t)) {
WARN_ON(t->next != NULL);
t->next = head->list;
head->list = t;
- raise_softirq_irqoff(TASKLET_SOFTIRQ);
+ raise_softirq_irqoff(nr);
tasklet_unlock(t);
}
}
@@ -367,7 +367,7 @@
unsigned long flags;

raw_local_irq_save(flags);
- __tasklet_common_schedule(t, &__get_cpu_var(tasklet_vec));
+ __tasklet_common_schedule(t, &__get_cpu_var(tasklet_vec), TASKLET_SOFTIRQ);
raw_local_irq_restore(flags);
}

@@ -378,7 +378,7 @@
unsigned long flags;

raw_local_irq_save(flags);
- __tasklet_common_schedule(t, &__get_cpu_var(tasklet_hi_vec));
+ __tasklet_common_schedule(t, &__get_cpu_var(tasklet_hi_vec), HI_SOFTIRQ);
raw_local_irq_restore(flags);
}

2006-03-06 13:25:54

by Ingo Molnar

[permalink] [raw]
Subject: Re: realtime-preempt patch-2.6.15-rt18 issues


* Rui Nuno Capela <[email protected]> wrote:

> Hi, Ingo,
>
> I think I would let you know that I'm still on 2.6.15-rt16, which
> works great for the most purposes, on all of my boxes.
>
> My problem is that the current/latest of the realtime-preempt patch,
> 2.6.15-rt18, has some showstoppers, at least for my day-to-day usage.
>
> First one, and I think this is a return of an old buglet. Its the one
> that occurs every time an usb-storage device is unplugged (e.g. a usb
> flash stick). Once that happens, the usb subsystem gets seriously
> crippled.
>
> Here goes a sample dmesg output of this occurrence (the complete listing
> is attached, as is the corresponding kernel .config).
>
> ...
> usb 2-1: USB disconnect, address 2
> slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free all
> objects

hm, this implicates the SLAB code. I've uploaded -rt19, does it work any
better [there i've included a newer version of the rt-SLAB code]? If you
still get the same problem even under -rt19, do things improve if you
enable CONFIG_EMBEDDED and CONFIG_SLOB?

(-rt19 also has the tasklet/ALSA fix, and some other fixlets)

Ingo

2006-03-06 15:12:04

by Rui Nuno Capela

[permalink] [raw]
Subject: Re: realtime-preempt patch-2.6.15-rt18 issues

Ingo,

> Rui Nuno Capela wrote:
>
>>
>> ...
>> usb 2-1: USB disconnect, address 2 slab error in kmem_cache_destroy():
>> cache `scsi_cmd_cache': Can't free all objects
>
> hm, this implicates the SLAB code. I've uploaded -rt19, does it work any
> better [there i've included a newer version of the rt-SLAB code]? If you
> still get the same problem even under -rt19, do things improve if you
> enable CONFIG_EMBEDDED and CONFIG_SLOB?
>
> (-rt19 also has the tasklet/ALSA fix, and some other fixlets)
>

-rt19 doesn't compile here (either with CONFIG_EMBEDDED=y or not):

...
CC mm/slab.o
mm/slab.c:703: error: request for member 'lock' in something not a
structure or union
mm/slab.c:703: error: request for member 'lock' in something not a
structure or union
mm/slab.c:703: error: request for member 'lock' in something not a
structure or union
mm/slab.c:703: error: request for member 'lock' in something not a
structure or union
mm/slab.c:703: error: initializer element is not constant
mm/slab.c:703: error: (near initialization for 'cache_cache.spinlock')
make[1]: *** [mm/slab.o] Error 1
make: *** [mm] Error 2


Cheers.
--
rncbc aka Rui Nuno Capela
[email protected]

2006-03-07 09:40:14

by Jan Altenberg

[permalink] [raw]
Subject: [PATCH] realtime-preempt patch-2.6.15-rt19 compile error (was: realtime-preempt patch-2.6.15-rt18 issues)

Hi,

> -rt19 doesn't compile here (either with CONFIG_EMBEDDED=y or not):

same problem here. Looks like a typo...
Am I right?

Signed-off-by: Jan Altenberg <[email protected]>

--------------------------------------------------

--- slab.c.orig 2006-03-07 10:27:35.000000000 +0100
+++ slab.c 2006-03-07 10:28:17.000000000 +0100
@@ -700,7 +700,7 @@ static struct kmem_cache cache_cache = {
.shared = 1,
.buffer_size = sizeof(struct kmem_cache),
.flags = SLAB_NO_REAP,
- .spinlock = SPIN_LOCK_UNLOCKED(&cache_cache.spinlock),
+ .spinlock = SPIN_LOCK_UNLOCKED(cache_cache.spinlock),
.name = "kmem_cache",
#if DEBUG
.obj_size = sizeof(struct kmem_cache),

2006-03-07 11:28:51

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] realtime-preempt patch-2.6.15-rt19 compile error (was: realtime-preempt patch-2.6.15-rt18 issues)


* Jan Altenberg <[email protected]> wrote:

> Hi,
>
> > -rt19 doesn't compile here (either with CONFIG_EMBEDDED=y or not):
>
> same problem here. Looks like a typo...
> Am I right?

> - .spinlock = SPIN_LOCK_UNLOCKED(&cache_cache.spinlock),
> + .spinlock = SPIN_LOCK_UNLOCKED(cache_cache.spinlock),

indeed - i've uploaded -rt20 with this fix.

Ingo

2006-03-07 12:35:26

by Rui Nuno Capela

[permalink] [raw]
Subject: Re: [PATCH] realtime-preempt patch-2.6.15-rt19 compile error (was: realtime-preempt patch-2.6.15-rt18 issues)

On Tue, March 7, 2006 09:40, Jan Altenberg wrote:
> Hi,
>
>
>> -rt19 doesn't compile here (either with CONFIG_EMBEDDED=y or not):
>>
>
> same problem here. Looks like a typo... Am I right?
>

OK. Apllited to -rt19 and tested it all in a hurry.

- The ALSA sequencer RTC timer issue, which was completely broken on
-rt18, seems to be solved. However, its way too early to tell a thing
about the mentioned system lockups.

- The SLAB related usb-storage crash on disconnect is still there:

usb 2-1: new full speed USB device using ohci_hcd and address 2
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
Vendor: USB 2.0 Model: Flash Disk Rev: 2.00
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 2031616 512-byte hdwr sectors (1040 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
SCSI device sda: 2031616 512-byte hdwr sectors (1040 MB)
sda: Write Protect is off
sda: Mode Sense: 0b 00 00 08
sda: assuming drive cache: write through
sda: sda1
sd 0:0:0:0: Attached scsi removable disk sda
usb-storage: device scan complete
usb 2-1: USB disconnect, address 2
slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free all
objects
[<c0141d1e>] kmem_cache_destroy+0x66/0xdb (8)
[<c020487c>] scsi_destroy_command_freelist+0x4e/0x5a (12)
[<c02054eb>] scsi_host_dev_release+0x4b/0x6e (12)
[<c01eaca7>] device_release+0x14/0x39 (12)
[<c019d07f>] kobject_cleanup+0x3e/0x5e (4)
[<c019d09f>] kobject_release+0x0/0x8 (8)
[<e054178c>] usb_stor_control_thread+0x0/0x183 [usb_storage] (8)
[<c019d7ce>] kref_put+0x3a/0x44 (4)
[<e05418ee>] usb_stor_control_thread+0x162/0x183 [usb_storage] (12)
[<c0272dc9>] schedule+0xd4/0xf5 (32)
[<c01226bf>] kthread+0x63/0x8f (20)
[<c012265c>] kthread+0x0/0x8f (12)
[<c0100d39>] kernel_thread_helper+0x5/0xb (16)


On reconnect, thereafter:

usb 2-1: new full speed USB device using ohci_hcd and address 3
kmem_cache_create: duplicate cache scsi_cmd_cache
[<c0141aab>] kmem_cache_create+0x439/0x469 (8)
[<c0157600>] __d_lookup+0xee/0xf8 (32)
[<c02047bb>] scsi_setup_command_freelist+0x60/0xd3 (36)
[<c020572f>] scsi_host_alloc+0x221/0x2ec (28)
[<c01ebea5>] __device_attach+0x0/0x5 (16)
[<e0541f44>] storage_probe+0x2b/0x1d0 [usb_storage] (4)
[<c01ebea5>] __device_attach+0x0/0x5 (24)
[<e002e071>] usb_probe_interface+0x4b/0x77 [usbcore] (4)
[<c01ebe56>] driver_probe_device+0x32/0x81 (12)
[<c01eb8cb>] bus_for_each_drv+0x36/0x58 (16)
[<c01ebee6>] device_attach+0x3c/0x4b (32)
[<c01ebea5>] __device_attach+0x0/0x5 (4)
[<c01eb996>] bus_add_device+0x20/0x75 (12)
[<c01eaf66>] device_add+0xd0/0x12e (20)
[<e0034612>] usb_set_configuration+0x31d/0x377 [usbcore] (20)
[<e002ffd2>] usb_new_device+0xef/0x148 [usbcore] (52)
[<e0030d7f>] hub_port_connect_change+0x260/0x302 [usbcore] (20)
[<e002ed50>] clear_port_feature+0x2b/0x30 [usbcore] (28)
[<e00310aa>] hub_events+0x289/0x34d [usbcore] (28)
[<c0272dc9>] schedule+0xd4/0xf5 (24)
[<e003116e>] hub_thread+0x0/0xcb [usbcore] (16)
[<e0031177>] hub_thread+0x9/0xcb [usbcore] (4)
[<c0122a57>] autoremove_wake_function+0x0/0x2d (12)
[<c01226bf>] kthread+0x63/0x8f (16)
[<c012265c>] kthread+0x0/0x8f (12)
[<c0100d39>] kernel_thread_helper+0x5/0xb (16)
[<c014ae4a>] lookup_bdev+0x1f/0x71 (20)
usb-storage: Unable to allocate the scsi host
usb-storage: probe of 2-1:1.0 failed with error -12


Complete dmesg and .config on attach, as usual.

Cheers.
--
rncbc aka Rui Nuno Capela
[email protected]


Attachments:
dmesg-2.6.15.5-rt19.0.gz (5.44 kB)
config-2.6.15.5-rt19.0.gz (9.56 kB)
Download all attachments

2006-03-10 07:44:33

by Jan Altenberg

[permalink] [raw]
Subject: Re: realtime-preempt patch-2.6.15-rt18 issues

Hi,

> - The SLAB related usb-storage crash on disconnect is still there:

I'm facing the same problem with -rt21. Kernel config, lspci -vvx
and dmesg output can be downloaded from:
http://www.tglx.de/private/tb10alj/rt21/

Unplugging the USB device causes:

slab error in kmem_cache_destroy(): cache `scsi_cmd_cache': Can't free all objects
[<c0161576>] kmem_cache_destroy+0xe9/0x11c (8)
[<c037eac7>] scsi_destroy_command_freelist+0x4b/0x79 (24)
[<c037fa47>] scsi_host_dev_release+0x46/0x8c (24)
[<c031559c>] device_release+0x1c/0x51 (16)
[<c02814b7>] kobject_cleanup+0x98/0x9a (16)
[<c02814b9>] kobject_release+0x0/0xa (12)
[<c03cf161>] usb_stor_control_thread+0x0/0x1a8 (8)
[<c0281e91>] kref_put+0x3d/0x80 (4)
[<c02814e1>] kobject_put+0x1e/0x22 (24)
[<c02814b9>] kobject_release+0x0/0xa (8)
[<c03cf2f5>] usb_stor_control_thread+0x194/0x1a8 (4)
[<c04a1091>] schedule+0x47/0x134 (36)
[<c011cfeb>] complete+0x4c/0x75 (4)
[<c0134bfd>] kthread+0xb1/0xb7 (36)
[<c0134b4c>] kthread+0x0/0xb7 (32)
[<c01013ed>] kernel_thread_helper+0x5/0xb (16)

After reconnecting:

kmem_cache_create: duplicate cache scsi_cmd_cache
[<c016112d>] kmem_cache_create+0x638/0x6ae (8)
[<c01398f1>] _spin_lock_init+0x2f/0x33 (52)
[<c037e9fd>] scsi_setup_command_freelist+0x8d/0x10c (24)
[<c013965a>] __init_MUTEX+0x20/0x28 (40)
[<c037fcc0>] scsi_host_alloc+0x233/0x360 (16)
[<c03cfa82>] storage_probe+0x36/0x221 (52)
[<c03b0bf0>] usb_probe_interface+0x7d/0xa8 (52)
[<c0317251>] driver_probe_device+0x69/0xd0 (24)
[<c03172b8>] __device_attach+0x0/0x5 (28)
[<c0316921>] bus_for_each_drv+0x65/0x7b (8)
[<c0317327>] device_attach+0x6a/0x6e (48)
[<c03172b8>] __device_attach+0x0/0x5 (16)
[<c0316a62>] bus_add_device+0x51/0xcc (12)
[<c03159bb>] device_add+0x122/0x198 (32)
[<c03b903f>] usb_set_configuration+0x2c3/0x430 (36)
[<c03b3585>] usb_new_device+0xe4/0x19d (80)
[<c03b46e2>] hub_port_connect_change+0x214/0x3df (40)
[<c03b000a>] cdrom_get_last_written+0xca/0x136 (28)
[<c03b4b72>] hub_events+0x2c5/0x427 (40)
[<c03b4ceb>] hub_thread+0x17/0xea (52)
[<c01350c1>] autoremove_wake_function+0x0/0x57 (12)
[<c01350c1>] autoremove_wake_function+0x0/0x57 (32)
[<c04a11dc>] preempt_schedule+0x5e/0x84 (20)
[<c03b4cd4>] hub_thread+0x0/0xea (16)
[<c0134bfd>] kthread+0xb1/0xb7 (4)
[<c0134b4c>] kthread+0x0/0xb7 (32)
[<c01013ed>] kernel_thread_helper+0x5/0xb (16)


Cheers,
JAN

2006-03-14 23:13:51

by Karsten Wiese

[permalink] [raw]
Subject: Re: [PATCH] realtime-preempt patch-2.6.15-rt19 compile error (was: realtime-preempt patch-2.6.15-rt18 issues)


--- Rui Nuno Capela <[email protected]> schrieb:
> - The SLAB related usb-storage crash on disconnect is
> still there:

and its still in up to rc6-rt3, unless you apply attached
patch. My uniprocessor behaves with it.

Ingo, what exactly needs fixing here?

cheers,
Karsten






___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


Attachments:
drain_cpu_caches.diff (332.00 B)
2948625469-drain_cpu_caches.diff

2006-03-15 09:33:42

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] realtime-preempt patch-2.6.15-rt19 compile error (was: realtime-preempt patch-2.6.15-rt18 issues)


* karsten wiese <[email protected]> wrote:

>
> --- Rui Nuno Capela <[email protected]> schrieb:
> > - The SLAB related usb-storage crash on disconnect is
> > still there:
>
> and its still in up to rc6-rt3, unless you apply attached patch. My
> uniprocessor behaves with it.

ah, indeed!

> Ingo, what exactly needs fixing here?

smp_call_function() will call things in a hardirq context, so calling
do_drain() from there [which uses preemptible spinlocks, etc.] is
unsafe. (it will work most of the time, but not all of the time) It
should rather be done from some per-CPU task.

a better fix would be the one below - it still does the call on the
current CPU, and skips other CPUs (on SMP). Does this solve the problem
on your box too?

Ingo

Index: linux-rt.q/mm/slab.c
===================================================================
--- linux-rt.q.orig/mm/slab.c
+++ linux-rt.q/mm/slab.c
@@ -2192,19 +2192,20 @@ static void check_spinlock_acquired_node
*/
static void smp_call_function_all_cpus(void (*func)(void *arg), void *arg)
{
- unsigned long flags;
+ unsigned int this_cpu;

check_irq_on();
- preempt_disable();
+// preempt_disable();

- slab_irq_disable(flags);
+ slab_irq_disable(this_cpu);
func(arg);
- slab_irq_enable(flags);
+ slab_irq_enable(this_cpu);

- if (smp_call_function(func, arg, 1, 1))
- BUG();
+// FIXME
+// if (smp_call_function(func, arg, 1, 1))
+// BUG();

- preempt_enable();
+// preempt_enable();
}

static void drain_array_locked(struct kmem_cache *cachep, struct array_cache *ac,
@@ -2231,8 +2232,7 @@ static void drain_cpu_caches(struct kmem
int this_cpu;
int node;

-// FIXME:
-// smp_call_function_all_cpus(do_drain, cachep);
+ smp_call_function_all_cpus(do_drain, cachep);
check_irq_on();
for_each_online_node(node) {
l3 = cachep->nodelists[node];

2006-03-15 10:19:43

by Jan Altenberg

[permalink] [raw]
Subject: Re: [PATCH] realtime-preempt patch-2.6.15-rt19 compile error (was: realtime-preempt patch-2.6.15-rt18 issues)

Hi,

> a better fix would be the one below - it still does the call on the
> current CPU, and skips other CPUs (on SMP). Does this solve the problem
> on your box too?

Tested in all a hurry and it seems to work for me too.

Cheers,
JAN

2006-03-15 11:07:19

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] realtime-preempt patch-2.6.15-rt19 compile error (was: realtime-preempt patch-2.6.15-rt18 issues)


* Jan Altenberg <[email protected]> wrote:

> > a better fix would be the one below - it still does the call on the
> > current CPU, and skips other CPUs (on SMP). Does this solve the problem
> > on your box too?
>
> Tested in all a hurry and it seems to work for me too.

a full fix is below: this re-enables the full SLAB related smp-call
functionality on PREEMPT_RT too (without any hackery), and fixes a
couple of rt-NUMA bugs as well.

Ingo

Index: linux-rt.q/mm/slab.c
===================================================================
--- linux-rt.q.orig/mm/slab.c
+++ linux-rt.q/mm/slab.c
@@ -147,9 +147,9 @@
# define slab_spin_unlock_irqrestore(lock, flags, cpu) \
do { spin_unlock_irqrestore(lock, flags); } while (0)
#else
-DEFINE_PER_CPU_LOCKED(int, slab_locks) = { 0, };
-# define slab_irq_disable(cpu) get_cpu_var_locked(slab_locks, &(cpu))
-# define slab_irq_enable(cpu) put_cpu_var_locked(slab_locks, cpu)
+DEFINE_PER_CPU_LOCKED(int, slab_irq_locks) = { 0, };
+# define slab_irq_disable(cpu) get_cpu_var_locked(slab_irq_locks, &(cpu))
+# define slab_irq_enable(cpu) put_cpu_var_locked(slab_irq_locks, cpu)
# define slab_irq_save(flags, cpu) \
do { slab_irq_disable(cpu); (void) (flags); } while (0)
# define slab_irq_restore(flags, cpu) \
@@ -989,7 +989,8 @@ static void __drain_alien_cache(struct k
/*
* Called from cache_reap() to regularly drain alien caches round robin.
*/
-static void reap_alien(struct kmem_cache *cachep, struct kmem_list3 *l3)
+static void
+reap_alien(struct kmem_cache *cachep, struct kmem_list3 *l3, int *this_cpu)
{
int node = __get_cpu_var(reap_node);

@@ -997,7 +998,7 @@ static void reap_alien(struct kmem_cache
struct array_cache *ac = l3->alien[node];
if (ac && ac->avail) {
spin_lock_irq(&ac->lock);
- __drain_alien_cache(cachep, ac, node);
+ __drain_alien_cache(cachep, ac, node, this_cpu);
spin_unlock_irq(&ac->lock);
}
}
@@ -1022,7 +1023,7 @@ static void drain_alien_cache(struct kme
#else

#define drain_alien_cache(cachep, alien) do { } while (0)
-#define reap_alien(cachep, l3) do { } while (0)
+#define reap_alien(cachep, l3, this_cpu) do { } while (0)

static inline struct array_cache **alloc_alien_cache(int node, int limit)
{
@@ -2164,14 +2165,6 @@ static void check_irq_on(void)
#endif
}

-static void check_spinlock_acquired(struct kmem_cache *cachep)
-{
-#ifdef CONFIG_SMP
- check_irq_off();
- assert_spin_locked(&cachep->nodelists[numa_node_id()]->list_lock);
-#endif
-}
-
static void check_spinlock_acquired_node(struct kmem_cache *cachep, int node)
{
#ifdef CONFIG_SMP
@@ -2183,39 +2176,57 @@ static void check_spinlock_acquired_node
#else
#define check_irq_off() do { } while(0)
#define check_irq_on() do { } while(0)
-#define check_spinlock_acquired(x) do { } while(0)
#define check_spinlock_acquired_node(x, y) do { } while(0)
#endif

+#ifdef CONFIG_PREEMPT_RT
+/*
+ * execute func() for all CPUs. On PREEMPT_RT we dont actually have
+ * to run on the remote CPUs - we only have to take their CPU-locks.
+ * (This is a rare operation, so cacheline bouncing is not an issue.)
+ */
+static void
+smp_call_function_all_cpus(void (*func)(void *arg, int this_cpu), void *arg)
+{
+ unsigned int i;
+
+ check_irq_on();
+ for_each_online_cpu(i) {
+ spin_lock(&__get_cpu_lock(slab_irq_locks, i));
+ func(arg, i);
+ spin_unlock(&__get_cpu_lock(slab_irq_locks, i));
+ }
+}
+#else
/*
* Waits for all CPUs to execute func().
*/
static void smp_call_function_all_cpus(void (*func)(void *arg), void *arg)
{
- unsigned long flags;
+ unsigned int this_cpu;

check_irq_on();
preempt_disable();

- slab_irq_disable(flags);
+ slab_irq_disable(this_cpu);
func(arg);
- slab_irq_enable(flags);
+ slab_irq_enable(this_cpu);

if (smp_call_function(func, arg, 1, 1))
BUG();

preempt_enable();
}
+#endif

static void drain_array_locked(struct kmem_cache *cachep, struct array_cache *ac,
int force, int node);

-static void do_drain(void *arg)
+static void __do_drain(void *arg, int this_cpu)
{
struct kmem_cache *cachep = (struct kmem_cache *) arg;
+ int node = cpu_to_node(this_cpu);
struct array_cache *ac;
- int node = numa_node_id();
- int this_cpu = smp_processor_id();

check_irq_off();
ac = cpu_cache_get(cachep, this_cpu);
@@ -2225,14 +2236,25 @@ static void do_drain(void *arg)
ac->avail = 0;
}

+#ifdef CONFIG_PREEMPT_RT
+static void do_drain(void *arg, int this_cpu)
+{
+ __do_drain(arg, this_cpu);
+}
+#else
+static void do_drain(void *arg)
+{
+ __do_drain(arg, smp_processor_id());
+}
+#endif
+
static void drain_cpu_caches(struct kmem_cache *cachep)
{
struct kmem_list3 *l3;
int this_cpu;
int node;

-// FIXME:
-// smp_call_function_all_cpus(do_drain, cachep);
+ smp_call_function_all_cpus(do_drain, cachep);
check_irq_on();
for_each_online_node(node) {
l3 = cachep->nodelists[node];
@@ -2759,7 +2781,7 @@ cache_alloc_refill(struct kmem_cache *ca
*/
batchcount = BATCHREFILL_LIMIT;
}
- l3 = cachep->nodelists[numa_node_id()];
+ l3 = cachep->nodelists[cpu_to_node(*this_cpu)];

BUG_ON(ac->avail > 0 || !l3);
spin_lock(&l3->list_lock);
@@ -2792,14 +2814,14 @@ cache_alloc_refill(struct kmem_cache *ca

slabp = list_entry(entry, struct slab, list);
check_slabp(cachep, slabp);
- check_spinlock_acquired(cachep);
+ check_spinlock_acquired_node(cachep, cpu_to_node(*this_cpu));
while (slabp->inuse < cachep->num && batchcount--) {
STATS_INC_ALLOCED(cachep);
STATS_INC_ACTIVE(cachep);
STATS_SET_HIGH(cachep);

ac->entry[ac->avail++] = slab_get_obj(cachep, slabp,
- numa_node_id());
+ cpu_to_node(*this_cpu));
}
check_slabp(cachep, slabp);

@@ -2818,7 +2840,7 @@ cache_alloc_refill(struct kmem_cache *ca

if (unlikely(!ac->avail)) {
int x;
- x = cache_grow(cachep, flags, numa_node_id(), this_cpu);
+ x = cache_grow(cachep, flags, cpu_to_node(*this_cpu), this_cpu);

// cache_grow can reenable interrupts, then ac could change.
ac = cpu_cache_get(cachep, *this_cpu);
@@ -2901,7 +2923,7 @@ ____cache_alloc(struct kmem_cache *cache
if (unlikely(current->mempolicy && !in_interrupt())) {
int nid = slab_node(current->mempolicy);

- if (nid != numa_node_id())
+ if (nid != cpu_to_node(*this_cpu))
return __cache_alloc_node(cachep, flags, nid, this_cpu);
}
#endif
@@ -3043,11 +3065,12 @@ static void free_block(struct kmem_cache
}
}

-static void cache_flusharray(struct kmem_cache *cachep, struct array_cache *ac, int *this_cpu)
+static void
+cache_flusharray(struct kmem_cache *cachep, struct array_cache *ac, int *this_cpu)
{
int batchcount;
struct kmem_list3 *l3;
- int node = numa_node_id();
+ int node = cpu_to_node(*this_cpu);

batchcount = ac->batchcount;
#if DEBUG
@@ -3117,11 +3140,11 @@ __cache_free(struct kmem_cache *cachep,
{
struct slab *slabp;
slabp = virt_to_slab(objp);
- if (unlikely(slabp->nodeid != numa_node_id())) {
+ if (unlikely(slabp->nodeid != cpu_to_node(*this_cpu))) {
struct array_cache *alien = NULL;
int nodeid = slabp->nodeid;
struct kmem_list3 *l3 =
- cachep->nodelists[numa_node_id()];
+ cachep->nodelists[cpu_to_node(*this_cpu)];

STATS_INC_NODEFREES(cachep);
if (l3->alien && l3->alien[nodeid]) {
@@ -3231,7 +3254,7 @@ void *kmem_cache_alloc_node(struct kmem_

cache_alloc_debugcheck_before(cachep, flags);
slab_irq_save(save_flags, this_cpu);
- if (nodeid == -1 || nodeid == numa_node_id() ||
+ if (nodeid == -1 || nodeid == cpu_to_node(this_cpu) ||
!cachep->nodelists[nodeid])
ptr = ____cache_alloc(cachep, flags, &this_cpu);
else
@@ -3508,18 +3531,31 @@ struct ccupdate_struct {
struct array_cache *new[NR_CPUS];
};

-static void do_ccupdate_local(void *info)
+static void __do_ccupdate_local(void *info, int this_cpu)
{
struct ccupdate_struct *new = (struct ccupdate_struct *)info;
struct array_cache *old;

check_irq_off();
- old = cpu_cache_get(new->cachep, smp_processor_id());
+ old = cpu_cache_get(new->cachep, this_cpu);

- new->cachep->array[smp_processor_id()] = new->new[smp_processor_id()];
- new->new[smp_processor_id()] = old;
+ new->cachep->array[this_cpu] = new->new[this_cpu];
+ new->new[this_cpu] = old;
}

+#ifdef CONFIG_PREEMPT_RT
+static void do_ccupdate_local(void *arg, int this_cpu)
+{
+ __do_ccupdate_local(arg, this_cpu);
+}
+#else
+static void do_ccupdate_local(void *info)
+{
+ __do_ccupdate_local(arg, smp_processor_id());
+}
+#endif
+
+
static int do_tune_cpucache(struct kmem_cache *cachep, int limit, int batchcount,
int shared)
{
@@ -3654,9 +3690,9 @@ static void drain_array_locked(struct km
*/
static void cache_reap(void *unused)
{
+ int this_cpu = raw_smp_processor_id();
struct list_head *walk;
struct kmem_list3 *l3;
- int this_cpu;

if (!mutex_trylock(&cache_chain_mutex)) {
/* Give up. Setup the next iteration. */
@@ -3678,12 +3714,13 @@ static void cache_reap(void *unused)

check_irq_on();

- l3 = searchp->nodelists[numa_node_id()];
- reap_alien(searchp, l3);
+ l3 = searchp->nodelists[cpu_to_node(this_cpu)];
+ reap_alien(searchp, l3, &this_cpu);
+
slab_spin_lock_irq(&l3->list_lock, this_cpu);

drain_array_locked(searchp, cpu_cache_get(searchp, this_cpu), 0,
- numa_node_id());
+ cpu_to_node(this_cpu));

if (time_after(l3->next_reap, jiffies))
goto next_unlock;
@@ -3692,7 +3729,7 @@ static void cache_reap(void *unused)

if (l3->shared)
drain_array_locked(searchp, l3->shared, 0,
- numa_node_id());
+ cpu_to_node(this_cpu));

if (l3->free_touched) {
l3->free_touched = 0;

2006-03-15 14:08:26

by Karsten Wiese

[permalink] [raw]
Subject: Re: [PATCH] realtime-preempt patch-2.6.15-rt19 compile error (was: realtime-preempt patch-2.6.15-rt18 issues)


--- Ingo Molnar <[email protected]> schrieb:

>
> * Jan Altenberg <[email protected]> wrote:
>
> > > a better fix would be the one below - it still does
> the call on the
> > > current CPU, and skips other CPUs (on SMP). Does this
> solve the problem
> > > on your box too?
> >
> > Tested in all a hurry and it seems to work for me too.
>
> a full fix is below: this re-enables the full SLAB
> related smp-call
> functionality on PREEMPT_RT too (without any hackery),
> and fixes a
> couple of rt-NUMA bugs as well.
>
Hand applied your full fix against 2.6.15-rt21 (local diff
attached).
Works fine here on uniprocessor, Thanks!

Karsten






___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


Attachments:
slab_fix.diff (8.28 kB)
3654053042-slab_fix.diff