|SUBJECT ||Subject: [LIU Comp Sci] [firstname.lastname@example.org: Re: Kernel thread scheduling]
|From owner-learn-outgoing-at-mrbrklyn.com Sun Mar 22 20:01:17 2015
Received: by mrbrklyn.com (Postfix)
id 467591612EE; Sun, 22 Mar 2015 20:01:17 -0400 (EDT)
Received: by mrbrklyn.com (Postfix, from userid 28)
id 344671612F0; Sun, 22 Mar 2015 20:01:17 -0400 (EDT)
Received: by mrbrklyn.com (Postfix, from userid 1000)
id BCB171612EF; Sun, 22 Mar 2015 20:01:16 -0400 (EDT)
Date: Sun, 22 Mar 2015 20:01:16 -0400
Subject: [LIU Comp Sci] [xerofoify-at-gmail.com: Re: Kernel thread scheduling]
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.5.21 (2010-09-15)
----- Forwarded message from nick -----
Date: Sun, 22 Mar 2015 19:30:34 -0400
To: Vincenzo Scotti , Anand Moon
Cc: Jeff Haran , "kernelnewbies-at-kernelnewbies.org"
Subject: Re: Kernel thread scheduling
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
On 2015-03-22 07:14 PM, Vincenzo Scotti wrote:
> Thank you for the example.
> I understand what are the scheduling mechanics depending on task->state.
> But suppose another situation.
> Let's say I change current state to TASK_INTERRUPTIBLE. If I start now some long
> operation, then shouldn't the scheduler kick in as soon as he can and put my thread
> asleep? Or should I call necessarily schedule()? And if so, why?
I would recommend reading Chapters 3 and 4 of Linux Kernel Development by Robert Love
as when I was learning the scheduler and process management for the kernel,I found these
chapters to be very useful.Further more for user space you are correct to my knowledge
schedule is called for internal tasks that are taking too long in kernel land or to
reschedule to another task,not for user space based tasks are TASK_INTERRUPTIBLE works
Hope this Helps,
> Kernelnewbies mailing list
Kernelnewbies mailing list
----- End forwarded message -----
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013