to schedule() or not to schedule() ?
Hi,
I have the following near the top of my cpufreq driver target routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
* schedule() here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
This is to prevent bad things from happening if someone is trying to change a parameter for the driver via sysfs while the target routine is running. Fortunately, because I had a bug where this bit was not getting cleared on one of the paths through the target routine ... I now know it is not safe to call schedule (it got stuck in there - knocked out my adb keyboard! - (I think target is called from a timer that the governor sets up ... interrupt context?)).
How does one very briefly yield the cpu in this context?
kevin
Quoted 15 lines · Kevin Diggs
Hi,
I have the following near the top of my cpufreq driver target routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
*schedule()here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
Quoted 1 line
This is to prevent bad things from happening if someone is trying to change a parameter for the driver via sysfs while the target routine is running. Fortunately, because I had a bug where this bit was not getting cleared on one of the paths through the target routine ... I now know it is not safe to call schedule (it got stuck in there - knocked out my adb keyboard! - (I think target is called from a timer that the governor sets up ... interrupt context?)).
Is the issue that someone may be in the middle of a multi-stage procedure, and you've woken up partway through?
If so, what about simply rescheduling the timer for some short time in the future and aborting the current call?
Chris
Quoted 18 lines · Chris Friesen
Quoted 16 lines · Kevin Diggs
Hi,
I have the following near the top of my cpufreq driver target
routine:while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
*schedule()here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
Quoted 9 lines
Quoted 1 line
This is to prevent bad things from happening if someone is trying to change a parameter for the driver via sysfs while the target routine is running. Fortunately, because I had a bug where this bit was not getting cleared on one of the paths through the target routine ... I now know it is not safe to call schedule (it got stuck in there - knocked out my adb keyboard! - (I think target is called from a timer that the governor sets up ... interrupt context?)).
Is the issue that someone may be in the middle of a multi-stage procedure, and you've woken up partway through?
If so, what about simply rescheduling the timer for some short time in the future and aborting the current call?
Chris
Chris,
Thanks for taking the time to reply. The parameter in question modifies
the frequency table. It is used several times in the target routine. I've addressed the issue by making a local copy of the frequency table upon entry to the target routine and use that while there. I don't care who wins the race.
kevin
Quoted 31 lines · Kevin Diggs
Quoted 24 lines · Chris Friesen
Quoted 13 lines · Kevin Diggs
I have the following near the top of my cpufreq driver target
routine:while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
*schedule()here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}Quoted 7 lines
This is to prevent bad things from happening if someone is trying to change a parameter for the driver via sysfs while the target routine is running. Fortunately, because I had a bug where this bit was not getting cleared on one of the paths through the target routine ... I now know it is not safe to call schedule (it got stuck in there - knocked out my adb keyboard! - (I think target is called from a timer that the governor sets up ... interrupt context?)).
Quoted 5 lines
Is the issue that someone may be in the middle of a multi-stage procedure, and you've woken up partway through?
If so, what about simply rescheduling the timer for some short time in the future and aborting the current call?
Quoted 7 lines
Chris,
Thanks for taking the time to reply. The parameter in question modifies
the frequency table. It is used several times in the target routine. I've addressed the issue by making a local copy of the frequency table upon entry to the target routine and use that while there. I don't care who wins the race.
How are you copying the table? Is it an atomic copy? Otherwise you could just end up copying the table while it's being updated, and you get a copy of the partially updated table.
Don't you just need a spinlock?
cheers
Signature · 8 lines
Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person
Quoted 34 lines · Michael Ellerman
Quoted 23 lines · Kevin Diggs
Quoted 21 lines · Chris Friesen
Quoted 13 lines · Kevin Diggs
I have the following near the top of my cpufreq driver target
routine:while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
*schedule()here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}Quoted 1 line
This is to prevent bad things from happening if someone is trying to change a parameter for the driver via sysfs while the target routine is running. Fortunately, because I had a bug where this bit was not getting cleared on one of the paths through the target routine ... I now know it is not safe to call schedule (it got stuck in there - knocked out my adb keyboard! - (I think target is called from a timer that the governor sets up ... interrupt context?)).
Is the issue that someone may be in the middle of a multi-stage procedure, and you've woken up partway through?
Quoted 7 lines
Quoted 1 line
If so, what about simply rescheduling the timer for some short time in the future and aborting the current call?
Chris,
Thanks for taking the time to reply. The parameter in question modifies
the frequency table. It is used several times in the target routine. I've addressed the issue by making a local copy of the frequency table upon entry to the target routine and use that while there. I don't care who wins the race.
Quoted 8 lines
How are you copying the table? Is it an atomic copy? Otherwise you could just end up copying the table while it's being updated, and you get a copy of the partially updated table.
Don't you just need a spinlock?
cheers
In the initialization routine I create 2 tables. One is a table with all the frequencies. The other has just the min and max. The parameter just changes a pointer to point to one table or the other. The above addressing of the issue should really say "a local copy of the pointer to the frequency table".
Thanks for the reply!
For the purpose of learning, there is no direct, correct way to yield the cpu when in a timer fired routine, right?
kevin
Quoted 3 lines · Kevin Diggs
For the purpose of learning, there is no direct, correct way to yield the cpu when in a timer fired routine, right?
No, in a timer, you interrupt a totally unrelated thread, so sleeping would prevent that from running on, as well as preventing other timers from being run, so it's not an option.
One thing that might work for you would be to re-arm the existing timer and return from your function, so you get back to it after a short while.
Arnd <><