Kernel configuration mostly-modular, based on standard SuSE kernel's
> > > /proc/config.gz, just compiling into the kernel everything I need to
> > > boot without an initrd and omitting some parts I'm not interested in.
> > > (.config attached.) What else might b
Kernel configuration mostly-modular, based on standard SuSE kernel's
> > > /proc/config.gz, just compiling into the kernel everything I need to
> > > boot without an initrd and omitting some parts I'm not interested in.
> > > (.config attached.) What else might b
#x27;m not interested in.
>> (.config attached.) What else might be relevant?
>>
>> Again, this is a Heisenbug, ie. it's not reproducible and invariably
>> happens when I'm away from the machine. (Probably Murphy at work.)
>> It's pretty rare: I have see
itting some parts I'm not interested in.
> > (.config attached.) What else might be relevant?
> >
> > Again, this is a Heisenbug, ie. it's not reproducible and invariably
> > happens when I'm away from the machine. (Probably Murphy at work.)
> > It's p
SuSE kernel's
> /proc/config.gz, just compiling into the kernel everything I need to
> boot without an initrd and omitting some parts I'm not interested in.
> (.config attached.) What else might be relevant?
>
> Again, this is a Heisenbug, ie. it's not reproducible and
t compiling into the kernel everything I need to
> boot without an initrd and omitting some parts I'm not interested in.
> (.config attached.) What else might be relevant?
>
> Again, this is a Heisenbug, ie. it's not reproducible and invariably
> happens when I'm away f
On a SuSE 10.0 system running kernel 2.6.21-rc3-mm2, it has now
happened for the 4th time that I came back after a couple of hours
to find that all KDE processes of the session I had left running had
died. The X server and applications (2x konsole, emacs, ksysguard)
were still running, but the K
Previously had #include , and mine just had
"struct task_struct;" instead for its forward references. asm-x86_64/elf.h
uses current->field in the ELF_CORE_COPY_REGS macro, expanded in
linux/elfcore.h in elf_core_copy_regs. So it needs sched.h but is no
longer getting it implicitly. Since curren
Peter Zijlstra a écrit :
Unfortunately not, nonlinear vmas don't have a linear relation between
address and offset. What you would need to do is do a linear walk of the
page tables. But even that might not suffice if nonlinear vmas may form
a non-injective, surjective mapping.
/me checks..
Hm
On Tue, 2007-03-20 at 16:32 +0100, Pierre Peiffer wrote:
> Peter Zijlstra a écrit :
> >> +static void *get_futex_address(union futex_key *key)
> >> +{
> >> + void *uaddr;
> >> +
> >> + if (key->both.offset & 1) {
> >> + /* shared mapping */
> >> + uaddr = (void*)((key->shared.pg
Sam Ravnborg wrote:
On Mon, Mar 19, 2007 at 05:27:11PM -0700, Randy Dunlap wrote:
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
- This is the same as 2.6.21-rc3-mm1, except Con's CPU sche
Peter Zijlstra a écrit :
+static void *get_futex_address(union futex_key *key)
+{
+ void *uaddr;
+
+ if (key->both.offset & 1) {
+ /* shared mapping */
+ uaddr = (void*)((key->shared.pgoff << PAGE_SHIFT)
+ + key->shared.offset
On Mon, Mar 19, 2007 at 05:27:11PM -0700, Randy Dunlap wrote:
> On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
> >
> > - This is the same as 2.6.21-rc3-m
nel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
> > >
> > > - This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
> > > were dropped.
> > >
> > > This is for A/B comparison purposes, and because those changes crashed
On Mon, 19 Mar 2007 17:27:11 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
> >
> > - This is the same
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
>
> - This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
> were dropped.
>
> This is for A/
On Mon, 2007-03-19 at 12:55 -0700, Andrew Morton wrote:
> On Mon, 19 Mar 2007 12:17:24 -0700
> Randy Dunlap <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
> >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/
On Mon, 19 Mar 2007 12:17:24 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
> >
> > - This is the same
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
>
> - This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
> were dropped.
>
> This is for A/
On Wed, 7 Mar 2007 20:19:15 -0800 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm2/
>
> - This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
> were dropped.
>
> This is for A/
On Mon, 19 Mar 2007 17:18:44 + Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> [applogies in advance if this has already been asked]
>
> I note that PG_booked and PG_readahead are both using bit 20 in
> 2.6.21-rc3-mm2. Is this intentional or perhaps a miss-merge. They do
>
[applogies in advance if this has already been asked]
I note that PG_booked and PG_readahead are both using bit 20 in
2.6.21-rc3-mm2. Is this intentional or perhaps a miss-merge. They do
not sound obviously non-overlapping to my mind.
-apw
-
To unsubscribe from this list: send the line
Len Brown wrote:
On Monday 12 March 2007 09:25, Luming Yu wrote:
try acpi=off please.
Ok, it boots up fine with acpi=off.
Now the next step is to try without the mm patch?
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
Hi!
> >> > Killing the known corner case starvation scenarios
> >is wonderful, but
> >> > let's not just pretend that interactive tasks don't
> >have any special
> >> > requirements.
> >>
> >> Now you're really making a stretch of things. Where
> >on earth did I say that
> >> interactive tasks
What follows is a patch series for the updated version of the Rotating
Staircase DeadLine cpu scheduler.
The dropping of one patch in the series and modest rewrite of certain
components means a fresh patch series is most appropriate, apologies for any
inconvenience.
Changes
- Implemented the
On Tue, 2007-03-13 at 10:52 +0100, [EMAIL PROTECTED] wrote:
> plain text document attachment (futex-requeue-pi.diff)
> This patch provides the futex_requeue_pi functionality.
>
> This provides an optimization, already used for (normal) futexes, to be used
> for
> PI-futexes.
>
> This optimizatio
Andrew Morton wrote:
> Well OK. But that doesn't actually explain why 64-bit mutexes are needed.
> It just says they are required.
I can show you the code but it's not easy to understand. For
complicated syn objects like rwlocks the state information is more than
just locked or not. Currently w
On Thu, 15 Mar 2007 12:12:11 -0700 Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Why do we want 64-bit futexes?
>
> I sent this to you already on 1/12/2007:
>
> http://udrepper.livejournal.com/13123.html
>
Well OK. But that doesn't actually explain why 64-bit mutexes ar
Andrew Morton wrote:
> Why do we want 64-bit futexes?
I sent this to you already on 1/12/2007:
http://udrepper.livejournal.com/13123.html
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
> On Tue, 13 Mar 2007 10:52:07 +0100 [EMAIL PROTECTED] wrote:
> This last patch is an adaptation of the sys_futex64 syscall provided in -rt
> patch (originally written by Ingo). It allows the use of 64bit futex.
>
> I have re-worked most of the code to avoid the duplication of the code.
>
> It do
Bjorn Helgaas <[EMAIL PROTECTED]> writes:
> In 2.6.21-rc3-mm2 (plus some move_freepages() bugfixes), I hit one
> of the warnings added by Eric's msi-debug-code.patch. This is on an
> ia64 box, an HP rx2600. Let me know if I can collect more information.
I think we are good
On Wed, 14 Mar 2007, Bjorn Helgaas wrote:
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
Virtual mem_map starts at 0xa0007fffc720
Zone PFN ranges:
Total aside, a message should have been printed out here with
"sizeof(struct page) = ??" when loglevel was set to 8. I wanted it so I
co
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
> >
> > Virtual mem_map starts at 0xa0007fffc720
> > Zone PFN ranges:
>
> Total aside, a message should have been printed out here with
> "sizeof(struct page) = ??" when loglevel was set to 8. I wanted it so I
> could work out PFNs from th
On Wed, 14 Mar 2007, Bjorn Helgaas wrote:
On Wednesday 14 March 2007 11:21, Mel Gorman wrote:
Can you tell me if the faulting line was at the check for PageBuddy?
I don't know, sorry.
No problem, the fact the patch booted lets me know that calling
PageBuddy() on an invalid page had the sa
Buddy() is called.
Boots fine with this patch:
Linux version 2.6.21-rc3-mm2 ([EMAIL PROTECTED]) (gcc version 4.0.3 (Debian
4.0.3-1)) #8 SMP Wed Mar 14 11:34:23 MST 2007
EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS=0x3fb3a000
HCDP=0x3fb2c000
booting generic kernel on platform
e faulting line was at the check for PageBuddy? Can you
also apply the following patch and boot with loglevel=8 please? The
patch moves the check for pfn_valid() before PageBuddy() is called.
Thanks
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.21-rc3-mm2-bjorn_testfix/mm/page_alloc
;,
+ __FUNCTION__, zone->name, zone->zone_start_pfn, start_page,
+ end_page);
+
#ifndef CONFIG_HOLES_IN_ZONE
/*
* page_zone is not safe to call in this context when
and it crashed like this. Let me know if I can collect more information
for you.
I'll
submit a patch that simply deletes this check because it should be redundant.
Just in case, I'd like to preserve the check in the non-HOLES_IN_ZONE
case for now.
Can you try this patch please? It should apply on top of Yasunori Goto's
patch.
Signed-off-by: Mel Gorman &
On Wednesday 14 March 2007 03:44, Mel Gorman wrote:
> Please try the following patch from Yasunori Goto.
> ...
> --- current_test.orig/mm/page_alloc.c 2007-03-08 15:44:10.0 +0900
> +++ current_test/mm/page_alloc.c 2007-03-08 16:17:29.0 +0900
> @@ -707,7 +707,7 @@ int move_freep
Yasunori Goto <[EMAIL PROTECTED]>
To: Andrew Morton <[EMAIL PROTECTED]>
Cc: linux-kernel@vger.kernel.org, Mel Gorman <[EMAIL PROTECTED]>
Subject: [PATCH] fix BUG_ON check at move_freepages() (Re: 2.6.21-rc3-mm2)
Hello.
The BUG_ON() check at move_freepages() is wrong.
Its end_page
On Wed, 2007-03-14 at 04:25 +0100, Gabriel C wrote:
> [EMAIL PROTECTED] wrote:
> > On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
> >
> >> with latest xorg, xlib will be using xcb internally,
> >>
> >
> > Out of curiosity, when is this "latest" Xorg going to escape to distros,
> >
FYI, I'm seeing the following oops with 2.6.21-rc3-mm1 (and -mm2)
on the HP rx2600 and an Intel Tiger (both ia64 boxes).
I haven't investigated this other than to determine that it
does not occur with 2.6.21-rc3 or 2.6.20-rc3-mm1, and the
instruction at move_freepages+0x10 is a load of the value
p
[EMAIL PROTECTED] wrote:
On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
with latest xorg, xlib will be using xcb internally,
Out of curiosity, when is this "latest" Xorg going to escape to distros,
Already is .. Xorg 7.2+ libx11 build with xcb enabled..
and is it far e
On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
> with latest xorg, xlib will be using xcb internally,
Out of curiosity, when is this "latest" Xorg going to escape to distros,
and is it far enough along that beta testers can gather usable numbers?
pgpt7KqlXv9Rp.pgp
Description: PGP sign
> a previous discussion that said 4 was the default...I don't see
> why. nice uses +10 by default on all linux distro...So I suspect
> that if Mike just used "nice lame" instead of "nice +5 lame", he
> would have got what he wanted.
tcsh, and probably csh, has a builtin 'nice' with default +4. So
On Tue, Mar 13, 2007 at 01:10:40PM -0700, Jeremy Fitzhardinge wrote:
> David Schwartz wrote:
> Hm, well. The general preference has been for the kernel to do a
> good-enough job on getting the common cases right without tuning, and
> then only add knobs for the really tricky cases it can't do well
On Tue, Mar 13, 2007 at 12:58:01PM -0700, David Schwartz wrote:
> > But saying that the user needs to explicitly hold the schedulers hand
> > and nice everything to tell it how to schedule seems to be an abdication
> > of duty, an admission of failure. We can't expect users to finesse all
> > thei
David Schwartz wrote:
>> There's a distinction between giving it more cpu and giving it higher
>> priority: the important part about having high priority is getting low
>> latency access to the cpu when its needed.
>>
>
> I agree. Tasks that voluntarily relinquish their timeslices should get l
> There's a distinction between giving it more cpu and giving it higher
> priority: the important part about having high priority is getting low
> latency access to the cpu when its needed.
I agree. Tasks that voluntarily relinquish their timeslices should get lower
latency compared to other proc
David Schwartz wrote:
> Good interactivity for tasks that aren't themselves CPU hogs. A task should
> get low latency if and only if it's yielding the CPU voluntarily most of the
> time. If it's not, it can only get better interactivity at the cost of
> fairness, and you have to *ask* for that. (Co
On Mon, 12 Mar 2007 20:06:43 BST, Xavier Bestel said:
> Le mardi 13 mars 2007 à 05:49 +1100, Con Kolivas a écrit :
> > Again I think your test is not a valid testcase. Why use two threads for
> > your
> > encoding with one cpu? Is that what other dedicated desktop OSs would do?
>
> One thought o
> "Serge" == Serge Belyshev <[EMAIL PROTECTED]> writes:
Serge> Mike Galbraith <[EMAIL PROTECTED]> writes:
Serge> [snip]
>> It seems to be a plain linear slowdown. The lurchiness I'm experiencing
>> varies in intensity, and is impossible to quantify. I see neither
>> lurchiness nor slowdown i
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > [...] The situation as we speak is that you can run cpu intensive
> > tasks while watching eye-candy. With RSDL, you can't, you feel the
> > non-interactive load instantly. [...]
>
> i have to agree with Mike that this is a material regression t
On Tue, Mar 13, 2007 at 10:33:18AM +0100, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 09:18 +0100, Ingo Molnar wrote:
>
> > Con, we want RSDL to /improve/ interactivity. Having new scheduler
> > interactivity logic that behaves /worse/ in the presence of CPU hogs,
> > which CPU hogs are even r
On Tue, 2007-03-13 at 14:41 +0300, Serge Belyshev wrote:
> Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> [snip]
> > It seems to be a plain linear slowdown. The lurchiness I'm experiencing
> > varies in intensity, and is impossible to quantify. I see neither
> > lurchiness nor slowdown in mainli
Mike Galbraith <[EMAIL PROTECTED]> writes:
[snip]
> It seems to be a plain linear slowdown. The lurchiness I'm experiencing
> varies in intensity, and is impossible to quantify. I see neither
> lurchiness nor slowdown in mainline through -j8.
>
Whaa? make -j8 on mainline makes my desktop box com
On Tue, 2007-03-13 at 21:06 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 20:39, Ingo Molnar wrote:
> > * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > I just retested with the encoders at nice 0, and the x/gforce combo is
> > > terrible. [...]
> >
> > ok. So nice levels had nothing to do
On Tue, Mar 13, 2007 at 08:41:05PM +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 20:29, Ingo Molnar wrote:
> > So the question is: if all tasks are on the same nice level, how does,
> > in Mike's test scenario, RSDL behave relative to the current
> > interactivity code?
...
> The only way t
On Tue, 2007-03-13 at 20:31 +1100, Con Kolivas wrote:
> nice on my debian etch seems to choose nice +10 without arguments contrary to
> a previous discussion that said 4 was the default. However 4 is a good value
> to use as a base of sorts.
I don't see why. nice uses +10 by default on all linux
On Tuesday 13 March 2007 20:39, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > I just retested with the encoders at nice 0, and the x/gforce combo is
> > terrible. [...]
>
> ok. So nice levels had nothing to do with it - it's some other
> regression somewhere. How does the van
This patch provides the futex_requeue_pi functionality.
This provides an optimization, already used for (normal) futexes, to be used for
PI-futexes.
This optimization is currently used by the glibc in pthread_broadcast, when
using "normal" mutexes. With futex_requeue_pi, it can be used with PRIO_
This last patch is an adaptation of the sys_futex64 syscall provided in -rt
patch (originally written by Ingo). It allows the use of 64bit futex.
I have re-worked most of the code to avoid the duplication of the code.
It does not provide the functionality for all architectures (only for x64 for
Hi Andrew,
This is a re-send of a series of patches concerning futexes (here after
is a short description)
Could you consider them for inclusion in -mm tree ?
All of them have already been discussed in January and have already
been included in -rt for a while. I think t
Today, all threads waiting for a given futex are woken in FIFO order (first
waiter woken first) instead of priority order.
This patch makes use of plist (pirotity ordered lists) instead of simple list in
futex_hash_bucket.
All non-RT threads are stored with priority MAX_RT_PRIO, causing them to b
This patch modifies futex_wait() to use an hrtimer + schedule() in place of
schedule_timeout().
schedule_timeout() is tick based, therefore the timeout granularity is
the tick (1 ms, 4 ms or 10 ms depending on HZ). By using a high resolution
timer for timeout wakeup, we can attain a much finer t
On Tuesday 13 March 2007 20:29, Ingo Molnar wrote:
> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > Well I guess you must have missed where I asked him if he would be
> > happy if I changed +5 metrics to do whatever he wanted and he refused
> > to answer me. [...]
>
> I'd say lets keep nice levels ou
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> I just retested with the encoders at nice 0, and the x/gforce combo is
> terrible. [...]
ok. So nice levels had nothing to do with it - it's some other
regression somewhere. How does the vanilla scheduler cope with the
exactly same workload? I.e.
On Tue, 2007-03-13 at 09:18 +0100, Ingo Molnar wrote:
> Con, we want RSDL to /improve/ interactivity. Having new scheduler
> interactivity logic that behaves /worse/ in the presence of CPU hogs,
> which CPU hogs are even reniced to +5, than the current interactivity
> code, is i think a non-sta
On Tuesday 13 March 2007 20:21, Con Kolivas wrote:
> On Tuesday 13 March 2007 19:18, Ingo Molnar wrote:
> > * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > [...] The situation as we speak is that you can run cpu intensive
> > > tasks while watching eye-candy. With RSDL, you can't, you feel the
>
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> Well I guess you must have missed where I asked him if he would be
> happy if I changed +5 metrics to do whatever he wanted and he refused
> to answer me. [...]
I'd say lets keep nice levels out of this completely for now - while
they should work _to
On Tuesday 13 March 2007 19:18, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > [...] The situation as we speak is that you can run cpu intensive
> > tasks while watching eye-candy. With RSDL, you can't, you feel the
> > non-interactive load instantly. [...]
>
> i have to agre
* Con Kolivas <[EMAIL PROTECTED]> wrote:
> > It's not "offensive" to me, it is a behavioral regression. The
> > situation as we speak is that you can run cpu intensive tasks while
> > watching eye-candy. With RSDL, you can't, you feel the
> > non-interactive load instantly. Doesn't the fact
On Tue, 2007-03-13 at 09:18 +0100, Ingo Molnar wrote:
> ps. please be nice to each other - both of you are long-time
> scheduler contributors who did lots of cool stuff :-)
It's no big deal, Con and I just seem to be oil and water. He'll have
to be oil, because water is already take. *evapo
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> [...] The situation as we speak is that you can run cpu intensive
> tasks while watching eye-candy. With RSDL, you can't, you feel the
> non-interactive load instantly. [...]
i have to agree with Mike that this is a material regression that cannot
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > It has been said that "perfection is the enemy of good". The two
> > interactive tasks receiving 40% cpu while two niced background jobs
> > receive 60% may well be perfect, but it's damn sure not good.
>
> Well, the real problem is really "serv
On Tue, 2007-03-13 at 16:53 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:
> > It's not "offensive" to me, it is a behavioral regression. The
> > situation as we speak is that you can run cpu intensive tasks while
> > watching eye-candy. With RSDL, you can't, y
On Tue, 2007-03-13 at 17:16 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 17:08, Mike Galbraith wrote:
> > Virtual or physical cores has nothing to do with the interactivity
> > regression I noticed. Two nice 0 tasks which combined used 50% of my
> > box can no longer share that box with tw
On Mon, 12 Mar 2007, Lee Revell wrote:
On 3/12/07, David Lang <[EMAIL PROTECTED]> wrote:
the problem comes when this isn't enough. if you have several CPU hogs on a
system, and they are all around the same priority level, how can the
scheduler
know which one needs the CPU the most for good in
On Tue, 2007-03-13 at 16:53 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:
> > I'm not trying to be pig-headed. I'm of the opinion that fairness is
> > great... until you strictly enforce it wrt interactive tasks.
>
> How about answering my question then since
On Tuesday 13 March 2007 17:08, Mike Galbraith wrote:
> Virtual or physical cores has nothing to do with the interactivity
> regression I noticed. Two nice 0 tasks which combined used 50% of my
> box can no longer share that box with two nice 5 tasks and receive the
> 50% they need to perform. Th
On Mon, 2007-03-12 at 17:38 -0400, michael chang wrote:
> Perhaps, Mike Galbraith, do you feel that it should be possible to use
> the CPU at 100% for some task and still maintain excellent
> interactivity?
Within reason, yes. Defining "reason" is difficult. As we speak, this
is possible to a m
On Tuesday 13 March 2007 00:53, Con Kolivas wrote:
> On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:
> > On Tue, 2007-03-13 at 09:51 +1100, Con Kolivas wrote:
> > > On 13/03/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > > As soon as your cpu is fully utilized, fairness looses or
> > > >
On Tuesday 13 March 2007 16:10, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 09:51 +1100, Con Kolivas wrote:
> > On 13/03/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > As soon as your cpu is fully utilized, fairness looses or interactivity
> > > loses. Pick one.
> >
> > That's not true unle
On Tue, 2007-03-13 at 09:51 +1100, Con Kolivas wrote:
> On 13/03/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > As soon as your cpu is fully utilized, fairness looses or interactivity
> > loses. Pick one.
>
> That's not true unless you refuse to prioritise your tasks
> accordingly. Let's take
On Mar 12, 2007, at 11:26:25, Linus Torvalds wrote:
So "good fairness" really should involve some notion of "work done
for others". It's just not very easy to do..
Maybe extend UNIX sockets to add another passable object type vis-a-
vis SCM_RIGHTS, except in this case "SCM_CPUTIME". You call
On 3/12/07, David Lang <[EMAIL PROTECTED]> wrote:
the problem comes when this isn't enough. if you have several CPU hogs on a
system, and they are all around the same priority level, how can the scheduler
know which one needs the CPU the most for good interactivity?
in some cases you may be able
On 3/12/07, michael chang <[EMAIL PROTECTED]> wrote:
Considering the concepts put out by projects such as BOINC and
[EMAIL PROTECTED], I wouldn't be thoroughly surprised by this ideology,
although I do question the particular way this test case is being run.
If Con actually implements SCHED_ID
On Mon, 12 Mar 2007, Mike Galbraith wrote:
On Tue, 2007-03-13 at 07:38 +1100, Con Kolivas wrote:
On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
Killing the known corner case starvation scenarios is wonderful, but
let's not just pretend that interactive tasks don't have any special
requ
On 13/03/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:
On Tue, 2007-03-13 at 07:38 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> >
> > Killing the known corner case starvation scenarios is wonderful, but
> > let's not just pretend that interactive tasks don't
On Tue, 2007-03-13 at 00:05 +0300, Serge Belyshev wrote:
> Mike Galbraith <[EMAIL PROTECTED]> writes:
>
> [snip]
> >> And let's not lose sight of things with this one testcase.
> >>
> >> RSDL fixes
> >> - every starvation case
> >> - all fairness isssues
> >> - is better 95% of the time on the de
On 3/12/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 05:49 +1100, Con Kolivas wrote:
> > On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> > > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > > Mike the c
Op Monday 12 March 2007, schreef Con Kolivas:
> > > If we fix 95% of the desktop and worsen 5% is that bad given how much
> > > else we've gained in the process?
> >
> > Killing the known corner case starvation scenarios is wonderful, but
> > let's not just pretend that interactive tasks don't have
Mike Galbraith <[EMAIL PROTECTED]> writes:
[snip]
>> And let's not lose sight of things with this one testcase.
>>
>> RSDL fixes
>> - every starvation case
>> - all fairness isssues
>> - is better 95% of the time on the desktop
>
> I don't know where you got that 95% number from. For the most pa
On Tue, 2007-03-13 at 07:38 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> >
> > Killing the known corner case starvation scenarios is wonderful, but
> > let's not just pretend that interactive tasks don't have any special
> > requirements.
>
> Now you're reall
On Mon, 2007-03-12 at 21:11 +0100, Mike Galbraith wrote:
> How would you go about ensuring that there won't be any cycles wasted?
SCHED_IDLE or otherwise nice 19
> Killing the known corner case starvation scenarios is wonderful, but
> let's not just pretend that interactive tasks don't have any
On Tuesday 13 March 2007 07:11, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 05:49 +1100, Con Kolivas wrote:
> > On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> > > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > > Mike the cpu is being proportioned out perfectly according to
>
On Mon, 2007-03-12 at 08:26 -0700, Linus Torvalds wrote:
>
> On Mon, 12 Mar 2007, Mike Galbraith wrote:
> >
> > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> >
> > > Mike the cpu is being proportioned out perfectly according to fairness as
> > > I
> > > mentioned in the prior email, y
On Tue, 2007-03-13 at 05:49 +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 01:34, Mike Galbraith wrote:
> > On Mon, 2007-03-12 at 22:23 +1100, Con Kolivas wrote:
> > > Mike the cpu is being proportioned out perfectly according to fairness as
> > > I mentioned in the prior email, yet X is gett
On Monday 12 March 2007 09:25, Luming Yu wrote:
> try acpi=off please.
>
> On 3/12/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
> > I went from 2.6.18-rc5-mm1 to 2.6.21-rc3-mm2
> > The computer now hangs solid during boot, at this point:
> >
> > usb 1-1
Xavier Bestel wrote:
> Le mardi 13 mars 2007 à 05:49 +1100, Con Kolivas a écrit :
> > Again I think your test is not a valid testcase. Why use two threads for
> > your encoding with one cpu? Is that what other dedicated desktop OSs
> > would do?
>
> as your scheduler
> is "strictly fair", won't tha
1 - 100 of 150 matches
Mail list logo
