On Tue, Apr 05, 2005 at 09:20:57PM -0400, Trond Myklebust wrote:
> ty den 05.04.2005 Klokka 11:46 (-0400) skreiv Benjamin LaHaise:
>
> > I can see that goal, but I don't think introducing iosems is the right
> > way to acheive it. Instead (and I'll start tackling this), how about
> > factoring
On Mon, Apr 11, 2005 at 10:57:37AM +0200, Ingo Molnar wrote:
>
> * Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
>
> > Let me re-phrase then: it is a must have only on PI, to make sure you
> > don't have a loop when doing it. Maybe is a consequence of the
> > algorithm I chose. -However- it
On Mon, Apr 11, 2005 at 03:31:41PM -0700, Perez-Gonzalez, Inaky wrote:
> If you are exposing the kernel locks to userspace to implement
> mutexes (eg POSIX mutexes), deadlock checking is a feature you want
> to have to complain with POSIX. According to some off the record
> requirements I've been g
On Mon, Apr 11, 2005 at 04:28:25PM -0700, Perez-Gonzalez, Inaky wrote:
> >From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
...
> API than once upon a time was made multithreaded by just adding
> a bunch of pthread_mutex_[un]lock() at the API entry point...
> without realizing that
On Wed, Apr 13, 2005 at 11:46:40AM -0400, Steven Rostedt wrote:
> On Tue, 2005-04-12 at 17:27 -0700, Daniel Walker wrote:
> > There is a great big snag in my assumptions. It's possible for a process
> > to hold a fusyn lock, then block on an RT lock. In that situation you
> > could have a high prio
On Wed, Jul 13, 2005 at 11:48:01AM -0700, Paul E. McKenney wrote:
> 1.Is use of spin_trylock() and spin_unlock() in hardirq code
> (e.g., rcu_check_callbacks() and callees) a Bad Thing?
> Seems to result in boot-time hangs when I try it, and switching
> to _raw_spin_trylock()
On Wed, Jul 13, 2005 at 03:06:38PM -0400, Steven Rostedt wrote:
> > 3. Since SPIN_LOCK_UNLOCKED now takes the lock itself as an
> > argument, what is the best way to initialize per-CPU
> > locks? An explicit initialization function, or is there
> > some way that I am missing to make a
On Mon, Jul 18, 2005 at 02:10:31PM +0200, Esben Nielsen wrote:
> Unfortunately, one of the goals of the preempt-rt branch is to avoid
> altering too much code. Therefore the type semaphore can't be removed
> there. Therefore the name still lingers ... :-(
This is where you failed. You assumed that
On Fri, Jul 15, 2005 at 09:16:55AM -0700, Daniel Walker wrote:
> I don't agree with that. But of course I'm always speaking from a real
> time perspective . PI is expensive , but it won't always be. However, no
> one is forcing PI on anyone, even if I think it's good ..
It depends on what kind of
On Fri, Apr 15, 2005 at 04:37:05PM -0700, Inaky Perez-Gonzalez wrote:
> By following your method, the pi engine becomes unnecesarily complex;
> you have actually two engines following two different propagation
> chains (one kernel, one user). If your mutexes/locks/whatever are the
> same with a dif
On Sat, Jul 09, 2005 at 10:22:07AM -0700, Daniel Walker wrote:
> PREEMPT_RT is not pre-tuned for every situation , but the bests
> performance is achieved when the system is tuned. If any of these tests
> rely on a low priority thread, then we just raise the priority and you
> have better performan
On Thu, Mar 17, 2005 at 04:20:26PM -0800, Paul E. McKenney wrote:
> 5. Scalability -and- Realtime Response.
...
> void
> rcu_read_lock(void)
> {
> preempt_disable();
> if (current->rcu_read_lock_nesting++ == 0) {
> current->rcu_re
On Fri, Mar 18, 2005 at 04:56:41AM -0800, Bill Huey wrote:
> On Thu, Mar 17, 2005 at 04:20:26PM -0800, Paul E. McKenney wrote:
> > 5. Scalability -and- Realtime Response.
> ...
>
> > void
> > rcu_read_lock(void)
> > {
> > preempt_disable();
> > if (current->rcu_
On Sun, Mar 20, 2005 at 05:57:23PM +0100, Manfred Spraul wrote:
> That was just one random example.
> Another one would be :
>
> drivers/chat/tty_io.c, __do_SAK() contains
>read_lock(&tasklist_lock);
>task_lock(p);
>
> kernel/sys.c, sys_setrlimit contains
>task_lock(current->group_lea
On Sun, Mar 20, 2005 at 01:38:24PM -0800, Bill Huey wrote:
> On Sun, Mar 20, 2005 at 05:57:23PM +0100, Manfred Spraul wrote:
> > That was just one random example.
> > Another one would be :
> >
> > drivers/chat/tty_io.c, __do_SAK() contains
> >read_lock(&tasklist_lock);
> >task_lock(p);
>
On Fri, Mar 18, 2005 at 05:55:44PM +0100, Esben Nielsen wrote:
> On Fri, 18 Mar 2005, Ingo Molnar wrote:
> > i really have no intention to allow multiple readers for rt-mutexes. We
> > got away with that so far, and i'd like to keep it so. Imagine 100
> > threads all blocked in the same critical se
On Tue, Mar 22, 2005 at 02:04:46AM -0800, Bill Huey wrote:
> RCU isn't write deterministic like typical RT apps are[, so] we can... (below
> :-))
...
> Just came up with an idea after I thought about how much of a bitch it
> would be to get a fast RCU multipule reader semantic (our current shared
On Tue, Mar 22, 2005 at 02:17:27AM -0800, Bill Huey wrote:
> > A notion of priority across a quiescience operation is crazy anyways[-,-] so
> > it would be safe just to use to the old rwlock-semaphore "in place" without
> > any changes or priorty handling add[i]tions. The RCU algorithm is only
> >
On Fri, Jan 28, 2005 at 08:45:46PM +0100, Ingo Molnar wrote:
> * Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > If you do have a highest interrupt case that causes all activity to
> > block, then rwsems may indeed fit the bill.
> >
> > In the NFS client code we may use rwsems in order to protect s
On Mon, Jan 31, 2005 at 05:29:10PM -0500, Bill Davidsen wrote:
> The problem hasn't changed in a few decades, neither has the urge of
> developers to make their app look good at the expense of the rest of the
> system. Been there and done that myself.
>
> "Back when" we had no good tools except
On Tue, Feb 01, 2005 at 11:10:48PM -0600, Jack O'Quin wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
> > (also, believe me, this is not arrogance or some kind of game on our
> > part. If there was a nice clean solution that solved your and others'
> > problems equally well then it would already b
On Wed, Feb 02, 2005 at 10:44:22AM -0600, Jack O'Quin wrote:
> Bill Huey (hui) <[EMAIL PROTECTED]> writes:
> > Also, as media apps get more sophisticated they're going to need some
> > kind of access to the some traditional softirq facilities, possibily
> &g
On Wed, Feb 02, 2005 at 10:21:00PM +0100, Ingo Molnar wrote:
> yes and no. You are right in that the individual workloads (e.g.
> softirqs) are not separated and identified/credited to the thread that
> requested them. (in part due to the fact that you cannot e.g. credit a
> thread for e.g. unreque
On Wed, Feb 02, 2005 at 01:14:05PM -0800, Bill Huey wrote:
> Step one in this is to acknowlege that Unix scheduling semantics is
> "inantiquated" with regard to media apps. Some notion of scoping needs to
bah, "inadequate".
> be put in.
>
> Everybody on the same page ?
bill
-
To unsubscribe fr
On Wed, Feb 02, 2005 at 05:59:54PM -0500, Paul Davis wrote:
> Actually, JACK probably is the most sophisticated media *framework* on
> the planet, at least inasmuch as it connects ideas drawn from the
> media world and OS research/design into a coherent package. Its not
> perfect, and we've just st
On Thu, Feb 03, 2005 at 08:54:24AM +1100, Peter Williams wrote:
> As Ingo said in an earlier a post, with a little ingenuity this problem
> can be solved in user space. The programs in question can be setuid
> root so that they can set RT scheduling policy BUT have their
> permissions set so th
On Thu, Feb 03, 2005 at 10:41:33PM +0100, Ingo Molnar wrote:
> * Bill Huey <[EMAIL PROTECTED]> wrote:
> > It's clever that they do that, but additional control is needed in the
> > future. jackd isn't the most sophisticate media app on this planet (not
> > too much of an insult :)) [...]
>
> i thi
On Tue, Jul 24, 2007 at 04:39:47PM -0400, Chris Snook wrote:
> Chris Friesen wrote:
>> We currently use CKRM on an SMP machine, but the only way we can get away
>> with it is because our main app is affined to one cpu and just about
>> everything else is affined to the other.
>
> If you're not ex
On Tue, Jul 24, 2007 at 05:22:47PM -0400, Chris Snook wrote:
> Bill Huey (hui) wrote:
> Well, you need enough CPU time to meet your deadlines. You need
> pre-allocated memory, or to be able to guarantee that you can allocate
> memory fast enough to meet your deadlines. This princ
Folks,
The official announcement.
http://www.netapp.com/news/press/news_rel_20070905
Dave Hitz's blog about it.
http://blogs.netapp.com/dave/
bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
On Fri, Jul 27, 2007 at 12:03:28PM -0700, Tong Li wrote:
> Thanks for the interest. Attached is a design doc I wrote several months
> ago (with small modifications). It talks about the two pieces of my design:
> group scheduling and dwrr. The description was based on the original O(1)
> schedule
On Fri, Jul 27, 2007 at 07:36:17PM -0400, Chris Snook wrote:
> I don't think that achieving a constant error bound is always a good thing.
> We all know that fairness has overhead. If I have 3 threads and 2
> processors, and I have a choice between fairly giving each thread 1.0
> billion cycle
On Sat, Jul 28, 2007 at 09:28:36PM +0200, jos poortvliet wrote:
> Your point here seems to be: this is how it went, and it was right. Ok, got
> that. Yet, Con walked away (and not just over SD). Seeing Con go, I wonder
> how many did leave without this splash. How many didn't even get involved at
On Sat, Jul 28, 2007 at 11:06:09PM +0200, Diego Calleja wrote:
> So your argument is that SD shouldn't have been merged either, because it
> would have resulted in one scheduler over the other?
My argument is that schedule development is open ended. Although having
a central scheduler to hack is a
On Sat, Jul 28, 2007 at 03:18:24PM -0700, Linus Torvalds wrote:
> I don't think anything was suppressed here.
I disagree. See below.
> You seem to say that more modular code would have helped make for a nicer
> way to do schedulers, but if so, where were those patches to do that?
> Con's patche
On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote:
> Absolutely.
>
> Con quit for his own reasons. Given that Con himself has said that CFS
> was _not_ why he quite, please discard this... bait. Anyone who's name
> isn't Con Kolivas, who pretends to speak for him is at the very leas
On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote:
> And I think you are digressing from the main issue, which is the empirical
> comparison of SD vs. CFS and to determine which is best. The root of all
> the scheduler fuss was the emotional reaction of SD's author on why his
> sc
On Sun, Jul 29, 2007 at 04:18:18PM -0700, Linus Torvalds wrote:
> Ingo posted numbers. Look at those numbers, and then I would suggest some
> people could seriously consider just shutting up. I've seen too many
> idiotic people who claim that Con got treated unfairly, without those
> people admi
On Wed, Jan 24, 2007 at 12:31:15PM +0100, Ingo Molnar wrote:
> * Bill Huey <[EMAIL PROTECTED]> wrote:
>
> > Patch here:
> >
> >
> > http://mmlinux.sourceforge.net/public/patch-2.6.20-rc2-rt2.2.lock_stat.patch
>
> hm, most of the review feedback i gave has not been addressed in the
> patch
On Thu, Jan 04, 2007 at 05:46:59AM +0100, Ingo Molnar wrote:
> thanks. It's looking better, but there's still quite a bit of work left:
>
> there's considerable amount of whitespace noise in it - lots of lines
> with space/tab at the end, lines with 8 spaces instead of tabs, etc.
These comments
On Tue, Dec 26, 2006 at 04:51:21PM -0800, Chen, Tim C wrote:
> Ingo Molnar wrote:
> > If you'd like to profile this yourself then the lowest-cost way of
> > profiling lock contention on -rt is to use the yum kernel and run the
> > attached trace-it-lock-prof.c code on the box while your workload is
On Sat, Dec 30, 2006 at 06:56:08AM -0800, Daniel Walker wrote:
> On Sat, 2006-12-30 at 12:19 +0100, Ingo Molnar wrote:
>
> >
> > - Documentation/CodingStyle compliance - the code is not ugly per se
> >but still looks a bit 'alien' - please try to make it look Linuxish,
> >if i apply this
On Tue, Jan 02, 2007 at 02:51:05PM -0800, Chen, Tim C wrote:
> Bill,
>
> I'm having some problem getting this patch to run stablely. I'm
> encoutering errors like that in the trace that follow:
>
> Thanks.
> Tim
>
> Unable to handle kernel NULL pointer dereference at 0008
Yes, thos
On Tue, Jan 02, 2007 at 03:12:34PM -0800, Bill Huey wrote:
> On Tue, Jan 02, 2007 at 02:51:05PM -0800, Chen, Tim C wrote:
> > Bill,
> >
> > I'm having some problem getting this patch to run stablely. I'm
> > encoutering errors like that in the trace that follow:
>
> It might the case that the lo
On Sat, Dec 30, 2006 at 12:19:40PM +0100, Ingo Molnar wrote:
> your patch looks pretty ok to me in principle. A couple of suggestions
> to make it more mergable:
>
> - instead of BUG_ON()s please use DEBUG_LOCKS_WARN_ON() and make sure
>the code is never entered again if one assertion has b
On Wed, Jan 03, 2007 at 03:59:28PM -0800, Chen, Tim C wrote:
> Bill Huey (hui) wrote:
> http://mmlinux.sourceforge.net/public/patch-2.6.20-rc2-rt2.2.lock_stat.patch
>
> This version is much better and ran stablely.
>
> If I'm reading the output correctly, the locks
On Wed, Jan 03, 2007 at 04:25:46PM -0800, Chen, Tim C wrote:
> Earlier I used latency_trace and figured that there was read contention
> on mm->mmap_sem during call to _rt_down_read by java threads
> when I was running volanomark. That caused the slowdown of the rt
> kernel
> compared to non-rt ke
On Wed, Jan 03, 2007 at 04:46:37PM -0800, Chen, Tim C wrote:
> Bill Huey (hui) wrote:
> > Can you sort the output ("sort -n" what ever..) and post it without
> > the zeroed entries ?
> >
> > I'm curious about how that statistical spike compares to the
On Wed, Jan 03, 2007 at 05:00:49PM -0800, Bill Huey wrote:
> On Wed, Jan 03, 2007 at 04:46:37PM -0800, Chen, Tim C wrote:
> > @contention events = 247149
> > @failure_events = 146
> > @lookup_failed_scope = 175
> > @lookup_failed_static = 43
> > @static_found = 16
> > [1, 113, 77 -- 32768, 0]
On Wed, Jan 03, 2007 at 05:11:04PM -0800, Chen, Tim C wrote:
> Bill Huey (hui) wrote:
> >
> > Thanks, the numbers look a bit weird in that the first column should
> > have a bigger number of events than that second column since it is a
> > special case subset. Looking a
On Wed, Jan 03, 2007 at 06:14:11PM -0800, Chen, Tim C wrote:
> Bill Huey (hui) wrote:
> http://mmlinux.sf.net/public/patch-2.6.20-rc2-rt2.3.lock_stat.patch
> > If you can rerun it and post the results, it'll hopefully show the
> > behavior of that lock acquisition better.
&
On Mon, Feb 26, 2007 at 09:35:43PM +0100, Ingo Molnar wrote:
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > If kernelspace rescheduling is that fast, then please explain me why
> > userspace one always beats kernel/userspace?
>
> because 'user space scheduling' makes no sense? I explained
On Tue, Feb 06, 2007 at 02:23:33PM +0100, Christoph Hellwig wrote:
> Iterate over sb->s_inodes instead of sb->s_files in add_dquot_ref.
> This reduces list search and lock hold time aswell as getting rid of
> one of the few uses of file_list_lock which Ingo identified as a
> scalability problem.
C
On Thu, Feb 08, 2007 at 01:01:21AM -0800, Bill Huey wrote:
> Christoph,
>
> The i_mutex lock the inode structure is also a source of contention
> heavy when running a lot of parallel "find"s. I'm sure that folks
> would be open to hearing suggestions regarding how to fix that.
Christoph,
And whi
On Thu, Feb 08, 2007 at 11:14:04PM -0800, Bill Huey wrote:
> I have an adaptive lock implementation in my tree that eliminates
> the contention between what looks like the IDE layer, work queues and
> the anticipatory scheduler, but that's not a real problem unlike what
> I've mentioned above. I ca
On Sun, Jan 28, 2007 at 03:30:06PM +, Christoph Hellwig wrote:
> On Sun, Jan 28, 2007 at 04:21:06PM +0100, Ingo Molnar wrote:
> > > > sb->s_files is converted to a lock_list. furthermore to prevent the
> > > > lock_list_head of getting too contended with concurrent add
> > > > operations the
On Sun, Jan 28, 2007 at 09:38:16AM -0800, Martin J. Bligh wrote:
> Christoph Hellwig wrote:
> >On Sun, Jan 28, 2007 at 08:52:25AM -0800, Martin J. Bligh wrote:
> >>Mmm. not wholly convinced that's true. Whilst i don't have lockmeter
> >>stats to hand, the heavy time in __d_lookup seems to indicate
On Sun, Jan 28, 2007 at 10:17:05PM +0100, Ingo Molnar wrote:
> btw., while my plan is to prototype your lock-stat patch in -rt
> initially, it should be doable to extend it to be usable with the
> upstream kernel as well.
>
> We can gather lock contention events when there is spinlock debugging
On Sun, Jan 28, 2007 at 09:27:45PM -0800, Bill Huey wrote:
> On Sun, Jan 28, 2007 at 10:17:05PM +0100, Ingo Molnar wrote:
> > btw., while my plan is to prototype your lock-stat patch in -rt
> > initially, it should be doable to extend it to be usable with the
> > upstream kernel as well.
...
> Fa
find this interesting or have been friendly with
me about -rt in the past.
bill
--- include/linux/lock_stat.h 5e0836a9785a182c8954c3bee8a92e63dd61602b
+++ include/linux/lock_stat.h 5e0836a9785a182c8954c3bee8a92e63dd61602b
@@ -0,0 +1,144 @@
+/*
+ * By Bill Huey (hui) at <[EMAIL PROTECTED]>
+ *
This hooks into the preexisting lock definitions in the -rt kernel and
hijacks parts of lockdep for the object hash key.
bill
--- include/linux/mutex.h d231debc2848a8344e1b04055ef22e489702e648
+++ include/linux/mutex.h 734c
Mods to rt.c and rtmutex.c
bill
--- init/main.c 268ab0d5f5bdc422e2864cadf35a7bb95958de10
+++ init/main.c 9d14ac66cb0fe3b90334512c0659146aec5e241c
@@ -608,6 +608,7 @@ asmlinkage void __init start_kernel(void
#ifdef CONFIG_PROC_FS
Rudimentary annotations to the lock initializers to avoid the binary
tree search before attachment. For things like inodes that are created
and destroyed constantly this might be useful to get around some
overhead.
Sorry, about the patch numbering order. I think I screwed up on it.
bill
===
On Sun, Dec 03, 2006 at 06:00:09PM -0800, Bill Huey wrote:
> Rudimentary annotations to the lock initializers to avoid the binary
> tree search before attachment. For things like inodes that are created
> and destroyed constantly this might be useful to get around some
> overhead.
>
> Sorry, about
On Mon, Dec 04, 2006 at 01:21:29PM +0100, bert hubert wrote:
> On Sun, Dec 03, 2006 at 05:53:23PM -0800, Bill Huey wrote:
>
> > [8264, 996648, 0] {inode_init_once, fs/inode.c, 196}
> > [8552, 996648, 0] {inode_init_once, fs/inode.c, 193}
>
> Impressive, Bill!
>
> How tightly
On Mon, Dec 04, 2006 at 09:08:56AM -0800, Bill Huey wrote:
> On Mon, Dec 04, 2006 at 01:21:29PM +0100, bert hubert wrote:
> > How tightly is your work bound to -rt? Iow, any chance of separating the
> > two? Or should we even want to?
>
> There's other uses for it as well. Think about RCU algorith
Containes .h file changes.
bill
--- include/linux/mutex.h d231debc2848a8344e1b04055ef22e489702e648
+++ include/linux/mutex.h 734c89362a3d77d460eb20eec3107e7b76fed938
@@ -15,6 +15,7 @@
#include
#include
#include
+#incl
Rough annotations to speed up the object attachment logic.
bill
--- arch/xtensa/platform-iss/network.c eee47b0ca011d1c327ce7aff0c9a7547695d3a1f
+++ arch/xtensa/platform-iss/network.c 76b16d29a46677a45d56b64983e0783959aa2160
@@ -648,6
Build system changes.
bill
--- kernel/Kconfig.preempt 3148bd94270ea0a853d8e443616cd7a668dd0d3b
+++ kernel/Kconfig.preempt d63831dbfbb9e68386bfc862fd2dd1a8f1e9779f
@@ -176,3 +176,12 @@ config RCU_TRACE
Say Y here i
(hui) at <[EMAIL PROTECTED]>
+ *
+ * Release under the what ever the Linux kernel chooses for a
+ * license, GNU Public License GPL v2
+ *
+ * Tue Sep 5 17:27:48 PDT 2006
+ * Created lock_stat.h
+ *
+ * Wed Sep 6 15:36:14 PDT 2006
+ * Thinking about the object lifetime of a spinlock.
.c files that have been changed, rtmutex.c, rt.c
--- kernel/rt.c 5fc97ed10d5053f52488dddfefdb92e6aee2b148
+++ kernel/rt.c 3b86109e8e4163223f17c7d13a5bf53df0e04d70
@@ -66,6 +66,7 @@
#include
#include
#include
+#include
#include
Hello,
I'm back with another annoying announcement and post of my "lock stat"
patches for Ingo's 2.6.19-rt14 patch. I want review, comments and
eventually inclusion into the -rt.
Changes in this release:
- forward ported to 2,6.19-rt14
- rt_mutex_slowtrylock() path now works with lock stat aft
On Mon, May 28, 2007 at 10:09:19PM +0530, Srivatsa Vaddagiri wrote:
> On Fri, May 25, 2007 at 10:14:58AM -0700, Li, Tong N wrote:
> > is represented by a weight of 10. Inside the group, let's say the two
> > tasks, P1 and P2, have weights 1 and 2. Then the system-wide weight for
> > P1 is 10/3 and
On Thu, Jun 07, 2007 at 02:17:45AM +0200, Martin Peschke wrote:
> Ingo Molnar wrote:
> >, quite some work went into it - NACK :-(
>
> Considering the amount of code.. ;-)I am sorry.
>
> But seriously, did you consider using some user space tool or script to
> format this stuff the way you lik
On Thu, Jun 07, 2007 at 09:30:21AM +0200, Ingo Molnar wrote:
> * Martin Peschke <[EMAIL PROTECTED]> wrote:
> > Do mean I might submit this stuff for -rt?
>
> Firstly, submit cleanup patches that _do not change the output_. If you
> have any output changes, do it as a separate patch, ontop of the
On Sun, May 13, 2007 at 05:38:53PM +0200, Ingo Molnar wrote:
> Even a simple 3D app like glxgears does a sys_sched_yield() for every
> frame it generates (!) on certain 3D cards, which in essence punishes
> any scheduler that implements sys_sched_yield() in a sane manner. This
> interaction of C
On Thu, May 17, 2007 at 05:18:41PM -0700, Bill Huey wrote:
> On Sun, May 13, 2007 at 05:38:53PM +0200, Ingo Molnar wrote:
> > Even a simple 3D app like glxgears does a sys_sched_yield() for every
> > frame it generates (!) on certain 3D cards, which in essence punishes
> > any scheduler that impl
On Sun, May 20, 2007 at 12:30:26PM +0200, Peter Zijlstra wrote:
> The 4 points are the first 4 unique callsites that cause lock contention
> for the specified lock class.
>
> writing a 0 to /proc/lockdep_contentions clears the stats
We should talk about unifying it with my lockstat work for -rt s
On Mon, May 21, 2007 at 08:08:28AM +0200, Ingo Molnar wrote:
> To me it appears Peter's stuff is already a pretty complete solution on
> its own, and it's a whole lot simpler (and less duplicative) than your
> lockstat patch. Could you list the specific items/features that you
> think Peter's st
On Mon, May 21, 2007 at 09:50:13AM +0200, Ingo Molnar wrote:
> Have you looked at the output Peter's patch produces? It prints out
> precise symbols:
>
> dcache_lock: 3000 0 [618] [] _atomic_dec_and_lock+0x39/0x58
>
> which can easily be turned into line numbers using debuginfo packages or
> u
On Mon, May 21, 2007 at 11:36:39AM +0200, Ingo Molnar wrote:
> you got the history wrong i think: the first version of lockdep was
> released to lkml a year ago (May 2006), while the first time you
> mentioned your lock contention patch was November 2006 and you released
> it to lkml in December
On Mon, May 21, 2007 at 10:55:47AM +0100, Christoph Hellwig wrote:
> On Mon, May 21, 2007 at 11:36:39AM +0200, Ingo Molnar wrote:
> > you got the history wrong i think: the first version of lockdep was
> > released to lkml a year ago (May 2006), while the first time you
> > mentioned your lock co
On Mon, May 21, 2007 at 03:19:46AM -0700, Bill Huey wrote:
> On Mon, May 21, 2007 at 11:36:39AM +0200, Ingo Molnar wrote:
> > you got the history wrong i think: the first version of lockdep was
> > released to lkml a year ago (May 2006), while the first time you
> > mentioned your lock contention
On Mon, May 21, 2007 at 02:46:55PM +0200, Ingo Molnar wrote:
> which combines into this statement of yours: "I audited 1600 something
> lock points in the kernel to convert the usage of C99 style initializers
> something more regular, only to find out that there wasn't much left to
> convert ove
On Mon, May 21, 2007 at 12:58:03PM +0200, Ingo Molnar wrote:
> and nobody pushed strong enough to get it included. But ... Peter's
> patch could perhaps be extended to cover similar stats as lockmeter,
> ontop of the existing lockdep instrumentation. Peter, can you see any
> particular roadblock
On Wed, May 23, 2007 at 09:58:35AM +0200, Xavier Bestel wrote:
> On Wed, 2007-05-23 at 07:23 +0200, Michael Gerdau wrote:
> > For me the huge difference you have for sd to the others increases the
> > likelyhood the glxgears benchmark does not measure scheduling of graphic
> > but something else.
>
On Wed, May 23, 2007 at 12:33:11PM +0200, Ingo Molnar wrote:
> * Peter Zijlstra <[EMAIL PROTECTED]> wrote:
...
> > It also measures lock wait-time and hold-time in nanoseconds. The
> > minimum and maximum times are tracked, as well as a total (which
> > together with the number of event can give
On Thu, Mar 08, 2007 at 10:31:48PM -0800, Linus Torvalds wrote:
> On Thu, 8 Mar 2007, Bill Davidsen wrote:
> > Please, could you now rethink plugable scheduler as well? Even if one had to
> > be chosen at boot time and couldn't be change thereafter, it would still
> > allow
> > a few new thoughts
On Tue, Mar 13, 2007 at 08:41:05PM +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 20:29, Ingo Molnar wrote:
> > So the question is: if all tasks are on the same nice level, how does,
> > in Mike's test scenario, RSDL behave relative to the current
> > interactivity code?
...
> The only way t
On Tue, Mar 13, 2007 at 12:58:01PM -0700, David Schwartz wrote:
> > But saying that the user needs to explicitly hold the schedulers hand
> > and nice everything to tell it how to schedule seems to be an abdication
> > of duty, an admission of failure. We can't expect users to finesse all
> > thei
On Tue, Mar 13, 2007 at 01:10:40PM -0700, Jeremy Fitzhardinge wrote:
> David Schwartz wrote:
> Hm, well. The general preference has been for the kernel to do a
> good-enough job on getting the common cases right without tuning, and
> then only add knobs for the really tricky cases it can't do well
On Fri, Apr 13, 2007 at 10:21:00PM +0200, Ingo Molnar wrote:
> [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
...
>The CFS patch uses a completely different approach and implementation
>from RSDL/SD. My goal was to make CFS's interactivity quality exceed
>
On Fri, Apr 13, 2007 at 02:21:10PM -0700, William Lee Irwin III wrote:
> On Fri, Apr 13, 2007 at 10:55:45PM +0200, Ingo Molnar wrote:
> > Yeah. Note that there are some subtle but crutial differences between
> > PlugSched (which Con used, and which i opposed in the past) and this
> > approach.
>
On Sat, Apr 14, 2007 at 01:18:09AM +0200, Ingo Molnar wrote:
> very much so! Both Con and Mike has contributed regularly to upstream
> sched.c:
The problem here is tha Con can get demotivated (and rather upset) when an
idea gets proposed, like SchedPlug, only to have people be hostile to it
and t
On Sat, Apr 14, 2007 at 10:04:23AM -0400, Mike Snitzer wrote:
> ZFS does have some powerful features but much of it depends on their
> broken layering of volume management. Embedding the equivalent of LVM
> into a filesystem _feels_ quite wrong.
They have a clustering concept in their volume mana
On Sun, Apr 15, 2007 at 01:27:13PM +1000, Con Kolivas wrote:
...
> Now that you're agreeing my direction was correct you've done the usual Linux
> kernel thing - ignore all my previous code and write your own version. Oh
> well, that I've come to expect; at least you get a copyright notice in the
On Sun, Apr 15, 2007 at 08:43:04AM +0200, Mike Galbraith wrote:
> [...]
>
> Demystify what? The casual observer need only read either your attempt
Here's the problem. You're a casual observer and obviously not paying
attention.
> at writing a scheduler, or my attempts at fixing the one we have
On Sun, Apr 15, 2007 at 10:44:47AM +0200, Ingo Molnar wrote:
> I prefer such early releases to lkml _alot_ more than any private review
> process. I released the CFS code about 6 hours after i thought "okay,
> this looks pretty good" and i spent those final 6 hours on testing it
> (making sure i
On Sun, Apr 15, 2007 at 09:25:07AM -0700, Arjan van de Ven wrote:
> Now this doesn't mean that people shouldn't be nice to each other, not
> cooperate or steal credits, but I don't get the impression that that is
> happening here. Ingo is taking part in the discussion with a counter
> proposal for
On Tue, Apr 17, 2007 at 04:52:08PM -0700, Michael K. Edwards wrote:
> On 4/17/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> >The ongoing scheduler work is on a much more basic level than these
> >affairs I'm guessing you googled. When the basics work as intended it
> >will be possible to m
1 - 100 of 589 matches
Mail list logo
