Date: Wed, 27 Aug 2008 15:23:14 -0700 (PDT)
Message-Id: <20080827.152314.218610441.davem@davemloft.net>
To: andi@firstfloor.org
Cc: dada1@cosmosbay.com, rick.jones2@hp.com, johnpol@2ka.mipt.ru,
       denys@visp.net.lb, netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: loaded router, excessive getnstimeofday in oprofile\
From: David Miller <davem@davemloft.net>
In-Reply-To: <20080827183216.GZ26610@one.firstfloor.org>
References: <20080827165635.GY26610@one.firstfloor.org>
	<48B58E6B.1030302@cosmosbay.com>
	<20080827183216.GZ26610@one.firstfloor.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 906
Lines: 22

From: Andi Kleen <andi@firstfloor.org>
Date: Wed, 27 Aug 2008 20:32:16 +0200

> > Doing the expensive timestamping in a possibly delayed thread (ie some 
> > milliseconds
> > after hardware notification) is wrong/useless.
> 
> We had this discussion earlier, please review the thread I linked to. 
> 
> Note that interrupts can be arbitarily delayed too (both by cli
> and by interrupt mitigation), even on a non RT kernel.

This is a much different kind of delay compared to sleeping for seconds
or longer on the socket lock while a GFP_KERNEL allocation is being
satisfied by swapping tons of crap out to disk.

Your socket solution is not a workable scheme.
--
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/