public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [patch] Real-Time Preemption, -RT-2.6.12-rc4-V0.7.47-06
@ 2005-05-23  8:26 Ingo Molnar
  2005-05-23  9:34 ` Serge Noiraud
                   ` (2 more replies)
  0 siblings, 3 replies; 41+ messages in thread
From: Ingo Molnar @ 2005-05-23  8:26 UTC (permalink / raw)
  To: linux-kernel; +Cc: dwalker, Joe King, ganzinger, Lee Revell, Steven Rostedt


i have released the -V0.7.47-06 Real-Time Preemption patch, which can be 
downloaded from the usual place:

    http://redhat.com/~mingo/realtime-preempt/

there was more stabilization activity during the past couple of weeks - 
i think i have all pending patches applied, let me know if something 
went MIA. I've also applied Mingming's ext3 reservation latency 
reductions.

Changes:

 - more plist fixes (Daniel Walker)

 - SMP global-RT-reschedule fix (Steven Rostedt)

 - x86_64 fixes - it builds & boots now (Joe King)

 - ext3 reservations latency reductions (Mingming Cao)

 - kstopmachine yield() fixes (Steven Rostedt)

 - ksoftirqd init fix (George Anzinger)

 - removed yield() uses from coredumping (suggested by many)

to build a -V0.7.47-06 tree, the following patches have to be applied:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc4.bz2
   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc4-V0.7.47-06

	Ingo

^ permalink raw reply	[flat|nested] 41+ messages in thread
* Re: [patch] Real-Time Preemption, -RT-2.6.12-rc4-V0.7.47-06
@ 2005-05-23 15:05 Oleg Nesterov
  2005-05-23 15:12 ` Daniel Walker
  0 siblings, 1 reply; 41+ messages in thread
From: Oleg Nesterov @ 2005-05-23 15:05 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, Daniel Walker, Inaky Perez-Gonzalez

Ingo Molnar wrote:
>
> Changes:
>
>  - more plist fixes (Daniel Walker)

plists were changed so that all nodes are tied via ->sp_node.

Now:

	#define plist_for_each(pos1, head)	\
		list_for_each_entry(pos1, &((head)->sp_node), sp_node)

This is correct.

	plist_for_each(curr1, &old_owner->pi_waiters) {
		w = plist_entry(curr1, struct rt_mutex_waiter, pi_list);
		if (w == waiter)
			goto ok;
	}

And this is not. because:

	#define plist_entry(ptr, type, member) \
		container_of(plist_first(ptr), type, member)
			     ^^^^^^^^^^^
	struct plist * plist_first(struct plist *plist)
	{
		return list_entry(plist->dp_node.next, struct plist, dp_node);
	}

So the very first node will be skipped, iteration will be out of order,
and you will have the plist's *head* as a last element (which is not
struct rt_mutex_waiter, of course).

>  unsigned plist_empty(const struct plist *plist)
>  {
> -	return list_empty (&plist->dp_node);
> +	return list_empty(&plist->dp_node) && list_empty(&plist->sp_node);
>  }

It's enough to check list_empty(&plist->sp_node) only.


And I don't understand why __plist_add_sorted is so complecated.
Why should we consider ->prio == INT_MAX as a special case?
This is also strange:

	new_sp_head:
		itr_pl2 = container_of(itr_pl->dp_node.prev, struct plist, dp_node);
		list_add(&pl->sp_node, &itr_pl2->sp_node);

Why?  Just list_add_tail(&pl->sp_node, itr_pl->sp_node), you don't
need itr_pl2 at all.

Daniel, if you accepted all-nodes-tied-via-sp_node idea, could you
also look at the code I've suggested. I think it is much simpler
and understandable.

void plist_add(struct plist *new, struct plist *head)
{
	struct plist* pos;

	INIT_LIST_HEAD(&new->dp_node);

	list_for_each_entry(pos, &head->dp_node, dp_node)
		if (new->prio < pos->prio)
			goto lt_prio;
		else if (new->prio == pos->prio) {
			pos = list_entry(pos->dp_node.next,
					 struct plist, dp_node);
			goto eq_prio;
		}

lt_prio:
	list_add_tail(&new->dp_node, &pos->dp_node);
eq_prio:
	list_add_tail(&new->sp_node, &pos->sp_node);
}

void plist_del(struct plist *del)
{
	if (!list_empty(&del->dp_node)) {
		struct plist *next = list_entry(del->sp_node.next,
						struct plist, sp_node);
		list_move_tail(&next->dp_node, &del->dp_node);
		list_del_init(&del->dp_node);
	}

	list_del_init(&del->sp_node);
}

Personally, I think it is better to have pl_head for plist's head,
and pl_node for nodes. It is pointless to store ->prio in the plist's
head, it can be found in plist_first()->prio. This way we can trim
the size of rt_mutex to 32 bytes, and it is good for typechecking.

Ingo, did you see these patches?
http://marc.theaimsgroup.com/?l=linux-kernel&m=111565001426673
http://marc.theaimsgroup.com/?l=linux-kernel&m=111565001415428
http://marc.theaimsgroup.com/?l=linux-kernel&m=111565001427334
http://marc.theaimsgroup.com/?l=linux-kernel&m=111565001408303
?

What do you think?

Oleg.

^ permalink raw reply	[flat|nested] 41+ messages in thread
* RE: [patch] Real-Time Preemption, -RT-2.6.12-rc4-V0.7.47-06
@ 2005-05-24  1:47 Perez-Gonzalez, Inaky
  0 siblings, 0 replies; 41+ messages in thread
From: Perez-Gonzalez, Inaky @ 2005-05-24  1:47 UTC (permalink / raw)
  To: Oleg Nesterov, Ingo Molnar; +Cc: linux-kernel, Daniel Walker

>From: tmp@several.ru [mailto:tmp@several.ru] On Behalf Of Oleg Nesterov
>Ingo Molnar wrote:
>>
>> Changes:
>>
>>  - more plist fixes (Daniel Walker)

>Why should we consider ->prio == INT_MAX as a special case?

This is a fusyn-specific optimization. INT_MAX is set to be the lowest
prio and the one used by non-PI waiters, so it will never interfere with
normal priorities. Because this is probably going to be most of the 
cases and we know it will always be the last one, it is a shortcut for
it.

It makes some sense, but in a more generic scenario, I might not.

-- Inaky 


^ permalink raw reply	[flat|nested] 41+ messages in thread
end of thread, other threads:[~2005-06-01 17:29 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-23  8:26 [patch] Real-Time Preemption, -RT-2.6.12-rc4-V0.7.47-06 Ingo Molnar
2005-05-23  9:34 ` Serge Noiraud
2005-05-23 11:23   ` Ingo Molnar
2005-05-23 14:30     ` K.R. Foley
2005-05-24 16:38 ` K.R. Foley
2005-05-25 11:34   ` Ingo Molnar
2005-05-25 11:35     ` Ingo Molnar
2005-05-25 13:28       ` K.R. Foley
2005-05-25 14:03         ` Ingo Molnar
2005-05-25 14:18           ` K.R. Foley
2005-05-25 15:20           ` K.R. Foley
2005-05-26  7:45           ` Ingo Molnar
2005-05-26 10:53             ` K.R. Foley
2005-05-26 15:23             ` K.R. Foley
2005-05-25 20:38 ` Michal Schmidt
2005-05-27 20:46   ` Michal Schmidt
2005-05-28  5:53     ` Ingo Molnar
2005-05-30  9:51       ` Michal Schmidt
2005-05-30 14:38         ` Ingo Molnar
2005-05-30 14:50           ` Ingo Molnar
2005-05-30 16:47             ` Michal Schmidt
2005-05-30 18:09               ` Ingo Molnar
2005-06-01 17:28       ` Esben Nielsen
2005-06-01  9:19   ` Ingo Molnar
2005-06-01  9:32     ` Michal Schmidt
2005-06-01  9:39       ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2005-05-23 15:05 Oleg Nesterov
2005-05-23 15:12 ` Daniel Walker
2005-05-23 15:53   ` Oleg Nesterov
2005-05-23 16:48   ` Oleg Nesterov
2005-06-01  9:21     ` Ingo Molnar
2005-06-01 13:04       ` Daniel Walker
2005-06-01 13:11         ` Ingo Molnar
2005-06-01 13:21           ` Daniel Walker
2005-06-01 14:43         ` Oleg Nesterov
2005-06-01 14:43           ` Daniel Walker
2005-06-01 15:02             ` Oleg Nesterov
2005-06-01 15:05               ` Daniel Walker
2005-06-01 15:47                 ` Oleg Nesterov
2005-06-01 15:43                   ` Daniel Walker
2005-05-24  1:47 Perez-Gonzalez, Inaky

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