gmane.linux.rt.user

Re: [PATCH v2] genirq: don't sync irq thread if current happen to be the very irq thread

Yong Zhang — 2012-05-23T06:54:58

Ah, yes :)


Yes.


I'll reconsider this issue and try to find the simpler way.

Thanks,
Yong
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] 3.0.32-rt52

Steven Rostedt — 2012-05-22T20:19:36

Dear RT Folks,

I'm pleased to announce the 3.0.32-rt52 stable release.


This release is just an update to the new stable 3.0.32 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  Head SHA1: 63166b1a384148473180f7bef83e71409e38de14


Or to build 3.0.32-rt52 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.32.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.32-rt52.patch.xz



Enjoy,

Re: [RFC][PATCH RT] rwsem_rt: Another (more sane) approach to mulit reader rt locks

Steven Rostedt — 2012-05-22T17:50:48

Agreed. I now have to find those that complained before, and see how
this patch can help. We need the patch to get the numbers (otherwise
it's a chicken vs egg deal).

I'd also like to see what problems would happen from taking all cpu
reader locks for a given writer.

I never said that this code must be merged. I want to see the numbers
too before we decide anything. I'll still clean up the patch and
hopefully we can get others to test it out and give their feedback.

Otherwise we're just hand waving back and forth at each other and it's
not fair because you have bigger hands that I do ;-)

Re: [RFC][PATCH RT] rwsem_rt: Another (more sane) approach to mulit reader rt locks

Thomas Gleixner — 2012-05-22T17:07:46


That still wants to be verified with numbers on a machine with at
least 32 cores and workloads which are mmap heavy. And before we don't
have such numbers we can really stop arguing about that solution.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH RT] rwsem_rt: Another (more sane) approach to mulit reader rt locks

Steven Rostedt — 2012-05-22T16:52:19


Perhaps we could just change the mmap_sem to use this approach. Create a
new type of rwsem/lock for -rt that we can be picky about.

Yeah, mmap_sem is a real PITA and it would be nice to have a solution
that can be used until we can convert it to an RCU lock.

Re: [RFC][PATCH RT] rwsem_rt: Another (more sane) approach to mulit reader rt locks

Steven Rostedt — 2012-05-22T15:50:01

For a box that has 64 CPUS, 8k should be nothing (even for every task).
But then again, NR_CPUS is compile time option. It would be nice if we
could make NR_CPUS just what was actually available :-/



We could always make this an option. I may be able to also do linker
tricks to make it a boot time option where the memory is allocated in
sections that can be freed if the option is not enabled. Just a thought,
I know this is making it more complex than necessary.


Well, it doesn't take NR_CPUS locks, it takes possible_cpus() locks,
which may be much smaller. As a compiled time NR_CPUS=64 running on a
box with just 4 cpus will do a loop of 4 and not 64.


I'm all for benchmarks. But right now, making all readers pass through a
single mutex is a huge bottle neck for a lot of loads. Yes, they are
mostly Java loads, but for some strange reason, our customers seems to
like to run Java on our RT kernel :-p

Re: [RFC][PATCH RT] rwsem_rt: Another (more sane) approach to mulit reader rt locks

Thomas Gleixner — 2012-05-22T15:26:38

So that will blow up every rw_semaphore user by

   NR_CPUS * sizeof(struct __rw_semaphore)

With lockdep off thats: NR_CPUS * 48

With lockdep on thats:  NR_CPUS * 128 + NR_CPUS * 8 (__key)

So for NR_CPUS=64 that's 3072 or 8704 Bytes.

That'll make e.g. XFS happy. xfs_inode has two rw_sems.

sizeof(xfs_inode) in mainline is:  856 bytes

sizeof(xfs_inode) on RT is:       1028 bytes

But with your change it would goto (NR_CPUS = 64):

    1028 - 96 + 2 * 3072 =        7076 bytes

That's almost an order of magnitude!

NFS has an rwsem in the inode as well, and ext4 has two.

So we trade massive memory waste for how much performance? 

We really need numbers for various scenarios. There are applications
which are pretty mmap heavy and it would really surprise me when
taking NR_CPUS locks in one go is not going to cause a massive
overhead.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  ht

[ANNOUNCE] 3.2.18-rt29

Steven Rostedt — 2012-05-22T15:01:48

Dear RT Folks,

I'm pleased to announce the 3.2.18-rt29 stable release.


This release is just an update to the new stable 3.2.18 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  Head SHA1: c96da77dcbdad05e0d707f443328e708f7cb024a


Or to build 3.2.18-rt29 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.18.xz

  http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.18-rt29.patch.xz



Enjoy,

Re: [PATCH v2] genirq: don't sync irq thread if current happen to be the very irq thread

Thomas Gleixner — 2012-05-22T13:50:38

You meant dereferencing *desc :)
 

And dereferencing action w/o being protected by desc->lock is buggy.

+while (action) {

Aside of that I really do not like that change. It'll hide real
deadlocks when disable_irq() is called from the interrupt handler.

Also this will not cure all problems of that MMC driver on RT or with
forced threaded interrupts.

Assume that tasklet code runs from the softirq thread so it will
schedule when desc->threads_active > 0. This will trigger a
"scheduling while atomic" warning.

The irq_enable/disable dance in that driver is amazing. I have no time
at the moment to grok the logic behind this, but it bet this can be
done way simpler and less horrible.

Thanks,

tglx

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RT 2/2] fix printk flush of messages

Frank Rowand — 2012-05-21T20:59:24

Yes, I goofed on the indentation, starting at console_trylock_for_printk().
It should have been:

   # some liberties taken in this pseudo-code to make it easier to follow
   printk()
      vprintk()
         raw_spin_lock(&logbuf_lock)
            # increment preempt_count():
            preempt_disable()
         result = console_trylock_for_printk()
            retval = 0
            # lock will always be false, because preempt_count() will be >= 1
            lock = ... && !preempt_count()
            if (lock)
               retval = 1
            return retval
         # result will always be false since lock will always be false
         if (result)
            console_unlock()
               # this is where the printk() output would be flushed

Thanks,

Frank

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch to fix early printks with PREMPT_RT_FULL

Venkat Subbiah — 2012-05-21T20:12:35

Frank,

Looks like the fix is not architecture specific. Curious as to why it 
doesn't show up
on ARM?

Thanks,
Venkat

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RT 2/2] fix printk flush of messages

Venkat Subbiah — 2012-05-21T20:10:56

So this is an issue for printk() itself and is not just for early_printk()?


    # some liberties taken in this pseudo-code to make it easier to follow
    printk()
       vprintk()
          raw_spin_lock(&logbuf_lock)
             # increment preempt_count():
             preempt_disable()
       result = console_trylock_for_printk()

As I read it console_trylock_for_printk() is called from printk() but in 
code it is called from vprintk()

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: patch to fix early printks with PREMPT_RT_FULL

Venkat Subbiah — 2012-05-21T19:54:15

The patch doe solve both #1 and #2. Thanks.
-Venkat


--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Real time micro benchmark suite - thread priority fix

John Kacur — 2012-05-21T15:59:25

I'm pretty sure he isn't either. In fact I bcced him on my first reply
to Venkat. I haven't had a good look at the benchmark yet to see if it
is anything we want to pick-up. It is the Eclipse license - I'd prefer
GPL. Do you regularly use this at IBM?

John
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Real time micro benchmark suite - thread priority fix

Nivedita Singhvi — 2012-05-21T15:36:22

I'm pretty sure Mike Fulton isn't maintaining it, but I'll ask around to 
see if anyone else is.

thanks,
Nivedita


--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Non-free firmware and proprietary Radeon driver on OSADL kernel

Carsten Emde — 2012-05-21T10:29:45

Yoann,

Have you considered a third possibility that this mailing list is about 
free software and you are asking a question about a commercial program? 
Please contact the vendor.

Alternatively, you may wish to help the community with the improvement 
of the free radeon driver. The mailing list is 
http://lists.x.org/mailman/listinfo/xorg-driver-ati.

-Carsten.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Real time micro benchmark suite - thread priority fix

John Kacur — 2012-05-21T10:15:11

On Mon, May 21, 2012 at 5:36 AM, Venkat Subbiah
<vsubbiah< at >caviumnetworks.com> wrote:


Okay. The Wiki contains a lot of historical material, plus it has been
down for quite awhile because of the kernel.org problems. Now that it
is back in service why don't you update the pages with the results of
your research. For example, if you find a benchmark / test that seems
to be defunct / not maintained, why not add a short note at the bottom
of the page saying so.

Thank you.

John Kacur
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Real time micro benchmark suite - thread priority fix

Venkat Subbiah — 2012-05-21T03:36:33

I got a list of benchmarks of the RT wiki and have been trying to 
exercise them. After looking into I do see that some of them are 
obscure. In the process ran into this and the fix I sent to
the maintainers bounced back, so wanted to send the fix out through
this forum.
Thanks,
Venkat

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Non-free firmware and proprietary Radeon driver on OSADL kernel

Yoann LE BARS — 2012-05-20T15:46:01

Hello everybody out there!

After reading a few messages from this list, I am not certain it is the
best place to ask my question. Also, I guess the reason nobody answers
is either nobody knows how sole my problem or have enough times to help
me. Anyway, I try and revive this topic: can anybody help me? Do I need
to give more information?

Regards.

Yoann

[PATCH v2] genirq: don't sync irq thread if current happen to be the very irq thread

Yong Zhang — 2012-05-20T12:19:26

Bad time for dereferencing *action.

---
From: Yong Zhang <yong.zhang< at >windriver.com>
Date: Sun, 20 May 2012 12:56:46 +0800
Subject: [PATCH v2] genirq: don't sync irq thread if current happen to be the very irq thread

Christophe reported against -rt http://marc.info/?l=linux-rt-users&m=133665600214984&w=2
BUG: scheduling while atomic: irq/37-s3c-mci/253/0x00000102
Modules linked in:
[<c000e9fc>] (unwind_backtrace+0x0/0x12c) from [<c029b82c>] (__schedule+0x58/0x2c0)
[<c029b82c>] (__schedule+0x58/0x2c0) from [<c029bc10>] (schedule+0x8c/0xb0)
[<c029bc10>] (schedule+0x8c/0xb0) from [<c0055614>] (synchronize_irq+0xbc/0xd8)
[<c0055614>] (synchronize_irq+0xbc/0xd8) from [<c01db6b0>] (pio_tasklet+0x34/0x11c)
[<c01db6b0>] (pio_tasklet+0x34/0x11c) from [<c0024914>] (__tasklet_action+0x68/0x80)
[<c0024914>] (__tasklet_action+0x68/0x80) from [<c0024ca4>] (__do_softirq+0x88/0x130)
[<c0024ca4>] (__do_softirq+0x88/0x130) from [<c0024ef0>] (do_softirq+0x48/0x54)
[<c0024ef0>] (do_softirq+0x48/0x54) from [<c0025048>] (local_

[PATCH] genirq: don't sync irq thread if current happen to be the very irq thread

Yong Zhang — 2012-05-20T05:27:31

Actually I don't think this is a -rt issue, you could also trigger this
warning with vanilla if you boot your kernel with 'threadirqs'.

Could you pleaes try the follow patch?

Thanks,
Yong

---
From: Yong Zhang <yong.zhang< at >windriver.com>
Date: Sun, 20 May 2012 12:56:46 +0800
Subject: [PATCH] genirq: don't sync irq thread if current happen to be the very irq thread

Christophe reported against -rt:
BUG: scheduling while atomic: irq/37-s3c-mci/253/0x00000102
Modules linked in:
[<c000e9fc>] (unwind_backtrace+0x0/0x12c) from [<c029b82c>] (__schedule+0x58/0x2c0)
[<c029b82c>] (__schedule+0x58/0x2c0) from [<c029bc10>] (schedule+0x8c/0xb0)
[<c029bc10>] (schedule+0x8c/0xb0) from [<c0055614>] (synchronize_irq+0xbc/0xd8)
[<c0055614>] (synchronize_irq+0xbc/0xd8) from [<c01db6b0>] (pio_tasklet+0x34/0x11c)
[<c01db6b0>] (pio_tasklet+0x34/0x11c) from [<c0024914>] (__tasklet_action+0x68/0x80)
[<c0024914>] (__tasklet_action+0x68/0x80) from [<c0024ca4>] (__do_softirq+0x88/0x130)
[<c0024ca4>] (__do_softirq+0x88/0x130) from [<