mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Arjan van de Ven <arjan@infradead.org>,
	linux-kernel@vger.kernel.org, mingo@elte.hu, tglx@tglx.de
Subject: Re: [PATCH 4/5] select: make select() use schedule_hrtimeout()
Date: Fri, 29 Aug 2008 11:46:00 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0808291140010.3300@nehalem.linux-foundation.org> (raw)
In-Reply-To: <20080829191837.3d2b3050@lxorguk.ukuu.org.uk>



On Fri, 29 Aug 2008, Alan Cox wrote:
> 
> Most of the timers we want to aggregate with are kernel originated and
> those also need accuracy fields (tcp retransmit is fairly precision at
> high speed while tcp keepalive is 'yeah whatever' sort of urgency.

Actually, I disagree.

They are _both_ of the exact same type: the precision depends on how long 
the timeout is.

TCP retransmit timers are a perfect example. If the timeout is long (which 
is quite common if you end up having multiple retransmits), you _really_ 
don't care about how precise it is.

And keepalives are 'yeah whatever' exactly because they are so long, not 
because they are inherently uninteresting per se.

I suspect you could find some kernel-generated timer that doesn't fit that 
pattern, but I can't really think of any.

> Agreed except that I'd assume real time tasks implied high accuracy,
> otherwise one assumes they'd have not have been real time - and probably
> putting those constants into sysfs somewhere.

And yes, I do agree that the heuristic could well involve other 
characteristics of the process in question. And probably characteristics 
of the machine itself (ie some general kind of "power mode" where timers 
are simply not considered critical if you want to be in low-power mode).

		Linus

  reply	other threads:[~2008-08-29 18:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-29 15:05 [patch 0/5] Nano/Microsecond resolution for select() and poll() Arjan van de Ven
2008-08-29 15:06 ` [PATCH 1/5] select: add a timespec version of the timeout to select/poll Arjan van de Ven
2008-08-30  2:10   ` Andrew Morton
2008-08-30  2:54     ` Linus Torvalds
2008-08-29 15:07 ` [PATCH 2/5] select: return accurate remainer in select() and ppoll() Arjan van de Ven
2008-08-29 15:07 ` [PATCH 3/5] select: introduce a schedule_hrtimeout() function Arjan van de Ven
2008-08-29 15:08 ` [PATCH 4/5] select: make select() use schedule_hrtimeout() Arjan van de Ven
2008-08-29 15:36   ` Arnd Bergmann
2008-08-29 15:59   ` Daniel Walker
2008-08-29 16:20   ` Linus Torvalds
2008-08-29 16:11     ` Alan Cox
2008-08-29 17:26       ` Linus Torvalds
2008-08-29 17:42         ` Arjan van de Ven
2008-08-29 18:18         ` Alan Cox
2008-08-29 18:46           ` Linus Torvalds [this message]
2008-08-29 18:33             ` Alan Cox
2008-08-30 15:25               ` Arjan van de Ven
2008-08-29 16:30     ` Arjan van de Ven
2008-08-29 15:08 ` [PATCH 5/5] select: make poll() use schedule_hrtimeout() as well Arjan van de Ven
2008-08-29 15:54 ` [patch 0/5] Nano/Microsecond resolution for select() and poll() Arnd Bergmann
2008-08-29 16:12   ` Arjan van de Ven
2008-08-29 22:15 ` Brian Wellington

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.1.10.0808291140010.3300@nehalem.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@tglx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®