Skip to contentSkip to conversation

set_current_state

Kernel-janitors Domen Puncer 3 participants 7 messages Jun 27, 2004 – Jun 30, 2004 Kernel janitors

lore
Share & tools
lore
#0 lore raw
Quoted 8 lines · Jay Bourque

New guy here,

I've been following the discussion lately and with talk about the TODO list badly needing updating, I was wondering how up to date the kj.pl script is. In particular, I ran it against the net/core/dev.c file and it showed that current->state needs to be changed to set_current_state. Is this still something that needs to be done?

Yes.
If you look at set_current_state, you see it's basically the same, with a memory barrier.

Quoted 7 lines

Thanks,
-Jay
_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

#1 lore raw

hi,

i just checked with the latest sources and there are 417 entries with 'current->state'. is a blind search-replace to set_current_state ok ?

can you please let me know ?

kind regards
anupam

Quoted 27 lines · Domen Puncer
Quoted 8 lines · Jay Bourque

New guy here,

I've been following the discussion lately and with talk about the TODO list badly needing updating, I was wondering how up to date the kj.pl script is. In particular, I ran it against the net/core/dev.c file and it showed that current->state needs to be changed to set_current_state. Is this still something that needs to be done?

Yes.
If you look at set_current_state, you see it's basically the same, with a memory barrier.

Quoted 7 lines

Thanks,
-Jay
_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

Quoted 2 lines

noname - 1K Download

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

#2 lore raw
In reply to Domen Puncer
Quoted 4 lines · Anupam Kapoor

hi,

i just checked with the latest sources and there are 417 entries with 'current->state'. is a blind search-replace to set_current_state ok ?

Yes, usualy.
Or maybe you should use __set_current_state (but do we really care that much about performance before schedule()?).

Opinions?

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

#3 lore raw
In reply to Domen Puncer
Quoted 11 lines · Domen Puncer
Quoted 4 lines · Anupam Kapoor

hi,

i just checked with the latest sources and there are 417 entries with 'current->state'. is a blind search-replace to set_current_state ok ?

Yes, usualy.
Or maybe you should use __set_current_state (but do we really care that much about performance before schedule()?).

Opinions?

hmm, i am not sure about this but does it make sense to use __set_current_state for functions that have fastcall ? and use set_current_state for others ?

kind regards
anupam

Quoted 1 line

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

#4 lore raw
In reply to Domen Puncer
Quoted 3 lines · Anupam Kapoor

hmm, i am not sure about this but does it make sense to use __set_current_state for functions that have fastcall ? and use set_current_state for others ?

It's not _that_ simple. We need set_current_state to racing if
instructions are reordered.

__set_current_state should *always* be used when setting to TASK_RUNNING.

But since function calls act also as memory barriers and most of the
locking primitives also have memory barriers built into them, there are few places where we actually need set_current_state (rather than __set_current_state).

Please check the LKML archives for further explanations.

But in short: No, it's not just a blind search-and-replace kind of thing.

Cheers,

Felipe

Signature · 2 lines
It's most certainly GNU/Linux, not Linux. Read more at
http://www.gnu.org/gnu/why-gnu-linux.html

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

#5 lore raw
In reply to Domen Puncer
Quoted 10 lines · Felipe W Damasio
Quoted 3 lines · Anupam Kapoor

hmm, i am not sure about this but does it make sense to use __set_current_state for functions that have fastcall ? and use set_current_state for others ?

It's not _that_ simple. We need set_current_state to racing if
instructions are reordered.

can you please elaborate what you mean here, i don't understand the connotations sorry !

Quoted 7 lines

__set_current_state should *always* be used when setting to TASK_RUNNING.

But since function calls act also as memory barriers and most of the
locking primitives also have memory barriers built into them, there are few places where we actually need set_current_state (rather than __set_current_state).

ah ok ! thanks for the explanation. i will check out lkml for more info.

kind regards
anupam

Quoted 12 lines

Please check the LKML archives for further explanations.

But in short: No, it's not just a blind search-and-replace kind of thing.

Cheers,

Felipe
--
It's most certainly GNU/Linux, not Linux. Read more at
http://www.gnu.org/gnu/why-gnu-linux.html

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors

#6 lore raw
In reply to Domen Puncer
Quoted 2 lines · Anupam Kapoor

can you please elaborate what you mean here, i don't understand the connotations sorry !

There's the classic example that rml used when he wrote a few
explanation notes of when set_current_state should be used.

If we're setting the current task to TASK_* (other than RUNNING) and
after that, manipulating some variable:

	current->state = TASK_INTERRUPTIBLE;
	if (doritos)
	{
		...
	}

	And on some of other code path we're checking to see if we're in 

TASK_INTERRUPTIBLE to also use the same variable:

	if (current->state == TASK_INTERRUPTIBLE)
	{
		do-something-to-doritos;
	}

	Then, in this case, we need a memory barrier the guarantee that the 

doritos variable will have the state set correctly _before_ manipulating it.

But again, state setting that are still open coded are not that simple
to see if we need set_current_state.

Most places it's not the end of the world to have an useless memory
barrier, but if we could things right and save an useless instruction..it'd be better.

In short: If in doubt, always use set_current_state. :-)

Cheers,

Felipe

Signature · 2 lines
It's most certainly GNU/Linux, not Linux. Read more at
http://www.gnu.org/gnu/why-gnu-linux.html

_______________________________________________
Kernel-janitors mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/kernel-janitors