Date: Thu, 24 Mar 2005 10:42:55 +0100 (MET)
From: Jan Engelhardt <jengelh@linux01.gwdg.de>
To: sounak chakraborty <sounakrin@yahoo.co.in>
cc: linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: sched.c  function
In-Reply-To: <20050324093352.43916.qmail@web53307.mail.yahoo.com>
Message-ID: <Pine.LNX.4.61.0503241038530.27454@yvahk01.tjqt.qr>
References: <20050324093352.43916.qmail@web53307.mail.yahoo.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1342
Lines: 34


>I had a wild idea to process one function that repeatedly checks the task list
>and find out which process is in which state

Why do not you do so, then? Note that on uniprocessors, all other tasks are
suspended, so their state does not change in between.

Tasks do not change their state without holding a lock. (There is an exception,
but it is justified.)

>I can run for_each process after certain interval of time, but rather than
>using timer i thought to set a value or call the function (for_each_process)
>whenever sheduling occurs(that is some process is going to sleep and some are
>awakening) that is i am getting some changes in the task list after that..

So you want to record task state changes? That is better done at the right
places in the kernel rather than traversing the task list repeatedly (the
latter is not that performant).

>i am sorry if some of my concepts are wrong as i am new to kernel and would be
>obliged if you correct me thank for your help sounak

I would be interested in the background: what do you need to know the task
states for?


Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/