Menu
▾
▴
ebs-linux-devel — EBS technical discussion
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: <ben...@id...> - 2004-05-25 09:35:45
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: John L. <jo...@au...> - 2004-02-28 05:53:23
|
On Fri, 27 Feb 2004, Peter Williams wrote:
> > static inline int sched_normal_effective_prio(task_t *p, runqueue_t *rq)
> > {
> > uint32_t eps;
> >
> > if (unlikely(0 == p->cpu_rate_cap_per_share)) {
> > if (user_mode(regs))
> > return EBS_BGND_PRI;
> > else
> > return EBS_MEAN_PRI;
> > }
> > ....
> >
> > Of course 'regs' is undefined above. I'll take a closer look at
> > user_mode() and struct pt_regs.
>
> OK
>
> BTW Should we think about doing something similar for capped tasks? Or
> is it unnecessary?
I think doing it for capped tasks won't be necessary. They'll at least get
to run again sooner or later.
However, even if user_mode() could be used, the above is not the complete
solution. To force a background task to call schedule() when it leaves the
kernel, we'll have to ensure that a background task _always_ has
need_resched set when executing in the kernel. If kernel preemption has
been enabled, this will require that every time schedule() chooses a BG
task in kernel mode to run, need_resched will need to be set for it.
Which then necessitates changing that need_resched() check at the end of
schedule() to account for BG tasks...
The alternative would be to make changes to the low level kernel
entry/exit code for each architecture to explicitly handle BG tasks -
probably not the way to go :-).
John
|
|
From: Peter W. <pe...@au...> - 2004-02-27 08:27:44
|
John Lee wrote:
> On Fri, 27 Feb 2004, Peter Williams wrote:
>
>
>>I think that a "flag" based solution to this problem would probably be
>>inadequate as there's no guarantee that a task only holds one semaphore
>>at a time. So I think that we should investigate a "count" based
>>solution.
>
>
> Wouldn't a better solution to this problem be to ensure that a background
> task running in kernel mode always get a highish priority? It can then
> finish its work in the kernel, be given its background priority back and
> call schedule().
>
> I don't know whether the user_mode() macro could be used within
> sched_normal_effective_prio(), but if it could solving this problem could
> simply be:
>
> static inline int sched_normal_effective_prio(task_t *p, runqueue_t *rq)
> {
> uint32_t eps;
>
> if (unlikely(0 == p->cpu_rate_cap_per_share)) {
> if (user_mode(regs))
> return EBS_BGND_PRI;
> else
> return EBS_MEAN_PRI;
> }
> ....
>
> Of course 'regs' is undefined above. I'll take a closer look at
> user_mode() and struct pt_regs.
OK
BTW Should we think about doing something similar for capped tasks? Or
is it unnecessary?
Peter
--
Dr Peter Williams, Chief Scientist pe...@au...
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
|
|
From: John L. <jo...@au...> - 2004-02-27 08:00:49
|
On Fri, 27 Feb 2004, Peter Williams wrote:
> I think that a "flag" based solution to this problem would probably be
> inadequate as there's no guarantee that a task only holds one semaphore
> at a time. So I think that we should investigate a "count" based
> solution.
Wouldn't a better solution to this problem be to ensure that a background
task running in kernel mode always get a highish priority? It can then
finish its work in the kernel, be given its background priority back and
call schedule().
I don't know whether the user_mode() macro could be used within
sched_normal_effective_prio(), but if it could solving this problem could
simply be:
static inline int sched_normal_effective_prio(task_t *p, runqueue_t *rq)
{
uint32_t eps;
if (unlikely(0 == p->cpu_rate_cap_per_share)) {
if (user_mode(regs))
return EBS_BGND_PRI;
else
return EBS_MEAN_PRI;
}
....
Of course 'regs' is undefined above. I'll take a closer look at
user_mode() and struct pt_regs.
John
|
|
From: Peter W. <pe...@au...> - 2004-02-27 01:14:53
|
I think that a "flag" based solution to this problem would probably be inadequate as there's no guarantee that a task only holds one semaphore at a time. So I think that we should investigate a "count" based solution. -- Dr Peter Williams, Chief Scientist pe...@au... Aurema Pty Limited Tel:+61 2 9698 2322 PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174 79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com |
