mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* Re: [patch] HT scheduler, sched-2.5.59-D7
@ 2003-01-20 21:59 Manfred Spraul
  2003-01-20 22:16 ` Ingo Molnar
  0 siblings, 1 reply; 10+ messages in thread
From: Manfred Spraul @ 2003-01-20 21:59 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

Ingo wrote:

>--- linux/fs/pipe.c.orig	2003-01-20 19:28:43.000000000 +0100
>+++ linux/fs/pipe.c	2003-01-20 22:58:35.000000000 +0100
>@@ -117,7 +117,7 @@
> 	up(PIPE_SEM(*inode));
> 	/* Signal writers asynchronously that there is more room.  */
> 	if (do_wakeup) {
>-		wake_up_interruptible(PIPE_WAIT(*inode));
>+		wake_up_interruptible_sync(PIPE_WAIT(*inode));
> 		kill_fasync(PIPE_FASYNC_WRITERS(*inode), SIGIO, POLL_OUT);
> 	}
> 	if (ret > 0)
>
What's the purpose of this change?
I thought that the _sync functions should be called if it's guaranteed 
that schedule() will be called immediately, i.e. if the scheduler should 
not rebalance.
You've added _sync() to the codepaths that lead to the end of the syscall.

--
    Manfred


^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [patch] sched-2.5.59-A2
@ 2003-01-20 19:52 Martin J. Bligh
  2003-01-20 21:18 ` [patch] HT scheduler, sched-2.5.59-D7 Ingo Molnar
  0 siblings, 1 reply; 10+ messages in thread
From: Martin J. Bligh @ 2003-01-20 19:52 UTC (permalink / raw)
  To: Andrew Theurer, Ingo Molnar
  Cc: Erich Focht, Michael Hohnbaum, Matthew Dobson, Christoph Hellwig,
	Robert Love, Linus Torvalds, linux-kernel, lse-tech,
	Anton Blanchard

>> > I have included a very rough patch to do ht-numa topology.  I requires to
>> > manually define CONFIG_NUMA and CONFIG_NUMA_SCHED.  It also uses
>> > num_cpunodes instead of numnodes and defines MAX_NUM_NODES to 8 if
>> > CONFIG_NUMA is defined.
>> 
>> Whilst it's fine for benchmarking, I think this kind of overlap is a
>> very bad idea long-term - the confusion introduced is just asking for
>> trouble. And think what's going to happen when you mix HT and NUMA.
>> If we're going to use this for HT, it needs abstracting out.
> 
> I have no issues with using HT specific bits instead of NUMA.  Design wise it 
> would be nice if it could all be happy together, but if not, then so be it.  

That's not what I meant - we can share the code, we just need to abstract
it out so you don't have to turn on CONFIG_NUMA. That was the point of
the pooling patch I posted at the weekend. Anyway, let's decide on the
best approach first, we can clean up the code for merging later.

M.


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2003-01-22 16:25 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-20 21:59 [patch] HT scheduler, sched-2.5.59-D7 Manfred Spraul
2003-01-20 22:16 ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2003-01-20 19:52 [patch] sched-2.5.59-A2 Martin J. Bligh
2003-01-20 21:18 ` [patch] HT scheduler, sched-2.5.59-D7 Ingo Molnar
2003-01-20 22:28   ` Andrew Morton
2003-01-21  1:11     ` Michael Hohnbaum
2003-01-22  3:15   ` Michael Hohnbaum
2003-01-22 16:41     ` Andrew Theurer
2003-01-22 16:17       ` Martin J. Bligh
2003-01-22 16:20         ` Andrew Theurer
2003-01-22 16:35       ` Michael Hohnbaum

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®