From: Oleg Nesterov <oleg@tv-sign.ru>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, Daniel Walker <dwalker@mvista.com>,
Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Subject: Re: [patch] Real-Time Preemption, -RT-2.6.12-rc4-V0.7.47-06
Date: Mon, 23 May 2005 19:05:24 +0400 [thread overview]
Message-ID: <4291F134.4338A50B@tv-sign.ru> (raw)
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.
next reply other threads:[~2005-05-23 14:57 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-23 15:05 Oleg Nesterov [this message]
2005-05-23 15:12 ` [patch] Real-Time Preemption, -RT-2.6.12-rc4-V0.7.47-06 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
-- strict thread matches above, loose matches on Subject: below --
2005-05-24 1:47 Perez-Gonzalez, Inaky
2005-05-23 8:26 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4291F134.4338A50B@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=dwalker@mvista.com \
--cc=inaky.perez-gonzalez@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox