* current->need_reshed, can it be a global flag ?
@ 2001-03-22 12:50 Parity Error
2001-03-22 18:45 ` george anzinger
0 siblings, 1 reply; 2+ messages in thread
From: Parity Error @ 2001-03-22 12:50 UTC (permalink / raw)
To: linux-kernel
instead of need_reshed being a per-task flag, could it be
as a global flag ?, since every time current->need_reshed
is checked, schedule() is just called to pick another
process.
---
Получите и Вы свой бесплатный электронный адрес на http://Mail.ru
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: current->need_reshed, can it be a global flag ?
2001-03-22 12:50 current->need_reshed, can it be a global flag ? Parity Error
@ 2001-03-22 18:45 ` george anzinger
0 siblings, 0 replies; 2+ messages in thread
From: george anzinger @ 2001-03-22 18:45 UTC (permalink / raw)
To: Parity Error; +Cc: linux-kernel
Parity Error wrote:
>
> instead of need_reshed being a per-task flag, could it be
> as a global flag ?, since every time current->need_reshed
> is checked, schedule() is just called to pick another
> process.
>
> ---
But for which cpu? Really this is a short cut to provide a per cpu area
that I think works very well, thank you.
Putting it in a real cpu data area would make access slower. The
"current" pointer is either very quickly computed or pre loaded in a
register (depends on the platform) so it is about as fast as it can get
as it is.
Also, the flag is often checked by selective preemption code in the
kernel. Even more often by the full preemption patch.
Nuf said
George
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2001-03-22 18:49 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-03-22 12:50 current->need_reshed, can it be a global flag ? Parity Error
2001-03-22 18:45 ` george anzinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox