From: Ingo Molnar <mingo@elte.hu>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: -mm merge plans for 2.6.20
Date: Wed, 6 Dec 2006 17:58:42 +0100 [thread overview]
Message-ID: <20061206165842.GA17755@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.64.0612061633230.1867@scrub.home>
* Roman Zippel <zippel@linux-m68k.org> wrote:
> > > > > [...] one obvious user would be the scheduler, [...]
> >
> > but that is not a refutation of what Thomas said, at all. You say
> > that the scheduler /could/ use such a facility. What Thomas said was
> > that /there are no current users of such a facility/. It is a really
> > simple (and unconditionally true) observation from Thomas. Yes, we
> > could change other kernel code not directly related to high-res
> > timers, but we chose not to.
>
> I didn't say "/could/", the scheduler _needs_ such a facility. [...]
i disagree that the scheduler unconditionally 'needs' such a facility.
The scheduler clock is pretty special and has other requirements and
constraints than generic timekeeping clocks. It /might/ and /could/
utilize such an infrastructure, but it's not at all clear that it
'needs' such a facility.
in any case, i very much entertain the possibility of more synergy in
this space, but it's far from obvious and it's definitely not
unconditionally 'necessary'. The scheduler and profiling code certainly
worked for 15 years without such synergy. What we concentrated on in
this patchset is high-resolution timers and dynticks, not scheduler or
profiler clock cleanups. We cleaned up everything that we impacted
directly, but we also tried to limit the scope of the changes wherever
possible.
Ingo
next prev parent reply other threads:[~2006-12-06 16:59 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-05 4:40 -mm merge plans for 2.6.20 Andrew Morton
2006-12-05 4:56 ` Jeff Garzik
2006-12-05 5:41 ` Andrew Morton
2006-12-05 7:04 ` Jens Axboe
2006-12-05 15:00 ` Mark Lord
2006-12-06 19:19 ` Conke Hu
2006-12-06 19:26 ` Randy Dunlap
2006-12-06 19:40 ` Jeff Garzik
2006-12-06 22:36 ` Andrew Morton
2006-12-05 5:14 ` Paul Mackerras
2006-12-05 5:42 ` Andrew Morton
2006-12-05 5:53 ` Nick Piggin
2006-12-05 5:49 ` Nick Piggin
2006-12-05 8:36 ` Gautham R Shenoy
2006-12-05 8:47 ` Peter Zijlstra
2006-12-05 11:06 ` ext2 future [was Re: -mm merge plans for 2.6.20] Pavel Machek
2006-12-05 13:23 ` -mm merge plans for 2.6.20 John W. Linville
2006-12-05 14:27 ` Roman Zippel
2006-12-06 3:46 ` Horst Schirmeier
2006-12-05 16:02 ` Dave Jones
2006-12-12 17:49 ` Dave Jones
2006-12-19 5:20 ` Nick Piggin
2006-12-19 6:44 ` Dave Jones
2006-12-19 7:02 ` Nick Piggin
2007-01-07 17:36 ` page_mapcount(page) went negative Dave Jones
2007-01-10 23:53 ` Nick Piggin
2006-12-05 17:35 ` -mm merge plans for 2.6.20 James Simmons
2006-12-05 18:01 ` Andrew Morton
2006-12-05 18:25 ` James Simmons
2006-12-05 18:37 ` [PATCH] backlight sysfs change to the fbdev drivers James Simmons
2006-12-05 18:37 ` James Simmons
2006-12-05 19:43 ` -mm merge plans for 2.6.20 Andrew Morton
2006-12-05 19:59 ` James Simmons
2006-12-05 20:20 ` Andrew Morton
2006-12-05 21:34 ` James Simmons
2006-12-06 23:40 ` Andrew Morton
2006-12-07 14:31 ` James Simmons
2006-12-05 20:40 ` Miguel Ojeda
2006-12-06 14:42 ` James Simmons
2006-12-05 19:18 ` Josef Sipek
2006-12-05 19:21 ` [PATCH 1/2] fsstack: Make fsstack_copy_attr_all copy inode size Josef Sipek
2006-12-05 19:22 ` [PATCH 2/2] fsstack: Fix up ecryptfs's fsstack usage Josef Sipek
2006-12-05 22:28 ` Andrew Morton
2006-12-05 22:38 ` Josef Sipek
2006-12-05 22:49 ` Andrew Morton
2006-12-05 23:16 ` Josef Sipek
2006-12-05 21:00 ` -mm merge plans for 2.6.20 Ingo Molnar
2006-12-05 21:17 ` -mm merge plans for 2.6.20, scheduler bits Ingo Molnar
2006-12-05 20:59 ` Siddha, Suresh B
2006-12-05 21:47 ` Ingo Molnar
2006-12-05 21:29 ` Miguel Ojeda
2006-12-06 2:59 ` -mm merge plans for 2.6.20 Roman Zippel
2006-12-06 4:30 ` Andrew Morton
2006-12-06 8:32 ` Thomas Gleixner
2006-12-06 12:54 ` Roman Zippel
2006-12-06 13:11 ` Ingo Molnar
2006-12-06 14:33 ` Roman Zippel
2006-12-06 15:22 ` Ingo Molnar
2006-12-06 16:42 ` Roman Zippel
2006-12-06 16:58 ` Ingo Molnar [this message]
2006-12-06 16:59 ` Ingo Molnar
2006-12-12 20:40 ` [RFC] HZ free ntp john stultz
2006-12-13 9:51 ` Ingo Molnar
2006-12-13 18:48 ` john stultz
2006-12-13 13:47 ` Roman Zippel
2006-12-13 19:19 ` john stultz
2006-12-13 20:40 ` Roman Zippel
2006-12-20 1:32 ` john stultz
2006-12-20 1:54 ` john stultz
2006-12-21 4:26 ` Andrew Morton
2007-01-01 18:29 ` Roman Zippel
2007-01-02 19:46 ` john stultz
2007-01-02 20:50 ` john stultz
2007-01-06 16:56 ` Roman Zippel
2007-01-22 19:27 ` [patch] HZ-free NTP Ingo Molnar
2007-01-22 19:39 ` Ingo Molnar
2007-01-01 16:27 ` [RFC] HZ free ntp Roman Zippel
2007-01-02 19:42 ` john stultz
2007-01-06 16:46 ` Roman Zippel
2006-12-06 12:33 ` -mm merge plans for 2.6.20 Roman Zippel
2006-12-08 14:09 ` Stephen Smalley
2006-12-08 20:58 ` Andrew Morton
2006-12-10 15:07 ` Mimi Zohar
2006-12-09 9:30 ` Randy Dunlap
2006-12-09 9:44 ` Andrew Morton
2006-12-10 20:12 ` Randy Dunlap
-- strict thread matches above, loose matches on Subject: below --
2006-12-05 23:55 Alessandro Guido
2006-12-06 0:13 ` Andrew Morton
2006-12-08 18:32 Steve French
2006-12-08 21:38 ` Andrew Morton
2006-12-10 3:18 Chuck Ebbert
2006-12-11 4:19 ` Steve French
2006-12-11 9:32 Chuck Ebbert
2006-12-13 1:09 Chuck Ebbert
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=20061206165842.GA17755@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=zippel@linux-m68k.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.