gmane.linux.rt.user

[PATCH] RFC - rt-tools: Detect whether numa is available at build time

John Kacur — 2012-05-25T23:39:49

This is a preliminary hack, I need to clean it up a little, but incase you
want to give it a try, here is the alpha version.

Note - I stole this methodology from tools/perf

Signed-off-by: John Kacur <jkacur< at >redhat.com>
---
 Makefile                 |   33 +++++++++++++++++++++++++++------
 config/feature-tests.mak |    8 ++++++++
 config/utilities.mak     |    7 +++++++
 3 files changed, 42 insertions(+), 6 deletions(-)
 create mode 100644 config/feature-tests.mak
 create mode 100644 config/utilities.mak

diff --git a/Makefile b/Makefile
index 3a82407..33f5027 100644
--- a/Makefile
+++ b/Makefile
< at >< at > -16,9 +16,6 < at >< at > srcdir?= $(prefix)/src
 
 machinetype = $(shell $(CC) -dumpmachine | \
     sed -e 's/-.*//' -e 's/i.86/i386/' -e 's/mips.*/mips/' -e 's/ppc.*/powerpc/')
-ifneq ($(filter x86_64 i386 ia64 mips powerpc,$(machinetype)),)
-NUMA := 1
-endif
 
 CFLAGS ?= -D_GNU_SOURCE -Wall -Wno-nonnull -Isrc/include
 LDFLAGS ?=
< at >< at > -31,9 +28,33 < at >< at > else
 CFLAGS+= -O0 -g
 endif
 
-ifeq ($(NUMA),1)
-CFLAGS += -DNUMA

RE: [PATCH][UPSTREAM]net,RT:Remove preemption disabling in netif_rx()

Steven Rostedt — 2012-05-25T22:43:56

I didn't like the get_cpu_light either, but I thought it was Peter that
was against a 'migrate-disable()' API leaking all over the kernel.

IIRC, he gave in when it was part of a locking internal infrastructure.
Now it's coming to what he was against. Maybe he changed his mind. I'll
let him speak for himself.

RE: [PATCH][UPSTREAM]net,RT:Remove preemption disabling in netif_rx()

Thomas Gleixner — 2012-05-25T22:31:20


No. get_cpu_light() and migrate_disable() are different.

Following your argument we would have to replace preempt_disable()
with get_cpu() all over the place.

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][UPSTREAM]net,RT:Remove preemption disabling in netif_rx()

Steven Rostedt — 2012-05-24T13:17:46


I really want to avoid placing open coded migrate_disable() around the
kernel. Perhaps we should use "get_cpu_light()" here too.

RE: [PATCH][UPSTREAM]net,RT:Remove preemption disabling in netif_rx()

Jain Priyanka-B32167 — 2012-05-24T04:28:20

Waiting for review comments on this.

Thanks
Priyanka

-----Original Message-----
From: Jain Priyanka-B32167 
Sent: Thursday, May 17, 2012 9:35 AM
To: linux-rt-users< at >vger.kernel.org
Cc: tglx< at >linutronix.de; rostedt< at >goodmis.orgn; Srivastava Rajan-B34330; Jain Priyanka-B32167
Subject: [PATCH][UPSTREAM]net,RT:Remove preemption disabling in netif_rx()

1)enqueue_to_backlog() (called from netif_rx) should be
  bind to a particluar CPU. This can be achieved by
  disabling migration. No need to disable preemption

2)Fixes crash "BUG: scheduling while atomic: ksoftirqd"
  in case of RT.
  If preemption is disabled, enqueue_to_backog() is called
  in atomic context. And if backlog exceeds its count,
  kfree_skb() is called. But in RT, kfree_skb() might
  gets scheduled out, so it expects non atomic context.

3)When CONFIG_PREEMPT_RT_FULL is not defined,  migrate_enable(), migrate_disable() maps to
 preempt_enable() and preempt_disable(), so no  change in functionality in case of non-RT.

-Replace preempt_enable(), pre

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