[PATCH] must fix list

[PATCH] must fix list

[Nick Piggin]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

Hi,
I don't know what happened to this, but I thought it was quite good.
Maybe I missed something?

Anyway I have removed AS from the list because it is done. I removed CFQ
as well because when the schedulers become runtime selectable (sometime
I hope), merging it becomes a non issue, even during the stable series I
think.

I updated the kernel/sched.c section a bit.

I moved 64-bit dev_t from should fix to must fix.

It looks like quite a bit can be struck off, but I'll leave it up to those
who actually did the work.

Maybe these should go in Documentation/must-fix/ to make patching and
syncing easier?


[-- Attachment #2: must-fix.patch --]
[-- Type: text/plain, Size: 3034 bytes --]

diff -Nrup old/must-fix-6.txt new/must-fix-6.txt
--- old/must-fix-6.txt	2003-09-17 14:58:13.000000000 +1000
+++ new/must-fix-6.txt	2003-09-17 15:03:49.000000000 +1000
@@ -270,28 +270,10 @@ o trond: NFS has a mmap-versus-truncate 
 kernel/sched.c
 ~~~~~~~~~~~~~~
 
-o "Persistent starvation"
+o Interactivity needs fixing. Con's patches are the most widely tested and
+  accepted.
 
-  http://www.hpl.hp.com/research/linux/kernel/o1-starve.php
-
-  ingo: "basically by calling sleep(1) in an infinite loop you can end up
-  expiring yourself.  The testcode (test-starve.c) triggers this.  This is
-  solved by going to sub-timeslices.  Which i've got done a few weeks ago and
-  it has seen some testing by others as well.
-
-o Overeager affinity in presence of repeated yields
-
-  http://www.hpl.hp.com/research/linux/kernel/o1-openmp.php
-
-  ingo: this is valid.  fix is in progress.
-
-o The "thud.c" test app.  This is a exploit for the interactivity
-  estimator.  it's unlikely to bite in real-world cases.  Needs watching. 
-  Can be ameliorated by setting nice values.
-
-o generic interactivity problems need watching.  We've closed down a number
-  of items recently without introducing new ones, so i'm confident this is
-  heading in the right direction.
+o Starvation, general interactivity need close monitoring.
 
 kernel/
 ~~~~~~~
@@ -442,6 +424,10 @@ o rmk: need to complete ALSA-ification o
 global
 ~~~~~~
 
+o 64-bit dev_t.  Seems almost ready, but it's not really known how much
+  work is still to do.  Patches exist in -mm but with the recent rise of the
+  neo-viro I'm not sure where things are at.
+
 o Lots of 2.4 fixes including some security are not in 2.5
 
 o HZ=1000 caused lots of lost timer interrupts.  ACPI or SMM.  (andi,
diff -Nrup old/should-fix-6.txt new/should-fix-6.txt
--- old/should-fix-6.txt	2003-09-17 14:58:13.000000000 +1000
+++ new/should-fix-6.txt	2003-09-17 15:09:44.000000000 +1000
@@ -12,18 +12,11 @@ drivers/block/
 
 o Framework for selecting IO schedulers.  This is the main one really. 
   Once this is in place we can drop in new schedulers any old time, no risk.
+  Jens has much of this code in place, but it needs the sysfs implementation
+  done.
 
   PRI1
 
-o Anticipatory scheduler.  Working OK now, still has problems with seeky
-  OLTP-style loads.
-
-  PRI1
-
-o CFQ scheduler.  Seems to work but Jens planning significant rework.
-
-  PRI2
-
 o cryptoloop: jmorris: There's no cryptoloop in the 2.4 mainline kernel,
   but I think every distro ships some version.  It would probably be useful
   to have crypto natively supported in 2.6, with backward compatibility for
@@ -380,12 +373,6 @@ o Pat: There are already CPU device stru
 global
 ~~~~~~
 
-o 64-bit dev_t.  Seems almost ready, but it's not really known how much
-  work is still to do.  Patches exist in -mm but with the recent rise of the
-  neo-viro I'm not sure where things are at.
-
-  PRI1
-
 o We need a kernel side API for reporting error events to userspace (could
   be async to 2.6 itself)
 

Re: [PATCH] must fix list

[Andrew Morton]

Nick Piggin <piggin@cyberone.com.au> wrote:
>
>  I don't know what happened to this, but I thought it was quite good.
>  Maybe I missed something?

It just didn't seem very relevant: people weren't keeping me up to date and
a lot of the patches which were going in weren't related to anything on the
lists.

>  Anyway I have removed AS from the list because it is done. I removed CFQ
>  as well because when the schedulers become runtime selectable (sometime
>  I hope), merging it becomes a non issue, even during the stable series I
>  think.
> 
>  I updated the kernel/sched.c section a bit.
> 
>  I moved 64-bit dev_t from should fix to must fix.
> 
>  It looks like quite a bit can be struck off, but I'll leave it up to those
>  who actually did the work.

Thanks.  Just for you, I'll do an update.

>  Maybe these should go in Documentation/must-fix/ to make patching and
>  syncing easier?

maybe...

Re: [PATCH] must fix list

[Nick Piggin]

Andrew Morton wrote:

>Nick Piggin <piggin@cyberone.com.au> wrote:
>
>> I don't know what happened to this, but I thought it was quite good.
>> Maybe I missed something?
>>
>
>It just didn't seem very relevant: people weren't keeping me up to date and
>a lot of the patches which were going in weren't related to anything on the
>lists.
>

I liked it. I think it gives you a good idea of the bigger changes
that need to happen and who is doing what. It might be a good idea to
keep around when you want to impose some sort of code freeze.

>
>> Anyway I have removed AS from the list because it is done. I removed CFQ
>> as well because when the schedulers become runtime selectable (sometime
>> I hope), merging it becomes a non issue, even during the stable series I
>> think.
>>
>> I updated the kernel/sched.c section a bit.
>>
>> I moved 64-bit dev_t from should fix to must fix.
>>
>> It looks like quite a bit can be struck off, but I'll leave it up to those
>> who actually did the work.
>>
>
>Thanks.  Just for you, I'll do an update.
>

Hows it going?

>
>> Maybe these should go in Documentation/must-fix/ to make patching and
>> syncing easier?
>>
>
>maybe...
>
>

IMO it would help