In-Reply-To: <43796596.2010908@watson.ibm.com>
References: <43796596.2010908@watson.ibm.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1F92A563-B430-49FE-895E-FB93DC64981E@comcast.net>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: 7bit
From: Parag Warudkar <kernel-stuff@comcast.net>
Subject: Re: [Patch 1/4] Delay accounting: Initialization
Date: Mon, 14 Nov 2005 23:25:24 -0500
To: Shailabh Nagar <nagar@watson.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1476
Lines: 40


On Nov 14, 2005, at 11:35 PM, Shailabh Nagar wrote:

> +/* because of hardware timer drifts in SMPs and task continue on  
> different cpu
> + * then where the start_ts was taken there is a possibility that
> + * end_ts < start_ts by some usecs. In this case we ignore the diff
> + * and add nothing to the total.

Curious as to when would this occur. Probably for tasks running on a  
SMP machine for a very short period of time (timer drift should not  
be hopefully that high) and switching CPUs in that short period of time?

> +config STATS_CONNECTOR
> +config DELAY_ACCT

Probably TASK_DELAY_STATS_CONNECTOR and TASK_DELAY_ACCOUNTING are  
better names?

> @@ -813,6 +821,9 @@ struct task_struct {
>  	int cpuset_mems_generation;
>  #endif
>  	atomic_t fs_excl;	/* holding fs exclusive resources */
> +#ifdef	CONFIG_DELAY_ACCT
> +	struct task_delay_info delays;
> +#endif
>  };

Does this mean, whether or not the per task delay accounting is used,  
we have a constant overhead of sizeof(spinlock_t) + 2*sizeof 
(uint32_t) + 2* sizeof(uint64_t) bytes going into the struct  
task_struct?. Is it possible/beneficial to use struct task_delay_info  
*delays instead and allocate it if task wants to use the information?

Parag
-
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/