2.6.19 -mm merge plans

Andrew Morton · External Since: Aug 22, 2004 Posts: 2442

On Thu, 21 Sep 2006 00:22:26 -0400
Jeff Garzik <jeff.TakeThisOut@garzik.org> wrote:

> Andrew Morton wrote:
> > A wander through the -mm patch queue, along with some commentary on my
> > intentions.
> >
> >
> > When replying to this email, please rewrite the Subject: to something
> > appropriate. Please also attempt to cc the appropriate developer(s).
> >
> >
> > There are quite a lot of patches here which belong in subsystem trees.
> > I'll patchbomb the relevant maintainers soon. Could I pleeeeeze ask that
> > they either merge the patches or solidly nack them (with reasons)? Don't
> > just ignore it all and leave me hanging onto this stuff for ever. Thanks.
>
> I know this is probably heresy, but what would happen if we didn't merge
> all that stuff at once, and then committed to having a real 4-week cycle?

(where'd 4 weeks come from?)

Why would a shorter cycle be better? What are we trying to achieve?

> The cycles seem to be stretching out again, and I don't really think
> it's worth it to hold up the entire kernel for every single piddly
> little regression to get fixed. We'll _never_ be perfect, even if we
> weren't slackers.
>

People seem to treat the stabilisation period as a wonderful quiet time in
which to run off and develop new features, rather than participating in the
stabilisation. This has the following effects:

1: release cycles get longer

2: the kernel has more bugs

3: we put new features into the kernel faster than we otherwise would
(see 2:, above).

Furthermore, in this period we have 60-odd disjoint trees which are based
on a relatively-slowly-changing mainline. This makes people think they are
free to go berzerk, leaving me bemusedly wondering why there are VFS and
NFS changes in the OCFS2 tree, SATA changes in the powerpc tree, SATA
changes in the scsi tree, configfs changes in the GFS2 tree,
every-goddam-thing changes in the driver tree, MM changes in the parisc
tree, etc, etc, etc.

If you think that shortening the release cycle will cause people to be more
disciplined in their changes, to spend less time going berzerk and to spend
more time working with our users and testers on known bugs then I'm all
ears.

So... it again comes down to "what are we trying to achieve"? Me, I'd
like to see people spending less time developing whizzy new things and more
time fixing bugs, tuning performance, etc. That would fix the lengthy
release cycle problem automatically.

What do _you_ want to achieve by making changes?

And a question. The current batch of git trees has:

2611 files changed, 295643 insertions(+), 130150 deletions(-)

How much of this has been suitably reviewed?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linus Torvalds · External Since: Jan 12, 2005 Posts: 517

On Wed, 20 Sep 2006, Andrew Morton wrote:
>
> Why would a shorter cycle be better? What are we trying to achieve?

I don't think a shorter cycle is necessarily better, but I think we could
try having a more "directed" cycle, and perhaps merge certain specific
things rather than everything.

That would possibly _cause_ a shorter cycle, if only because the problems
are hopefully more focused from the fact that we merged with a certain
focus.

Of course, it would likely just frustrate the people who didn't get
merged, and would need to wait for the next cycle. So it might be a net
negative, even if we'd bring individual cycles in a bit.

> > The cycles seem to be stretching out again, and I don't really think
> > it's worth it to hold up the entire kernel for every single piddly
> > little regression to get fixed. We'll _never_ be perfect, even if we
> > weren't slackers.

I think that's true. 2.6.18 got delayed partly due to me beign away, but I
also think that it then got delayed too much afterwards too, just because
I felt a bit nervous about having been away Wink

So it definitely stretched out too much.

Whether there is a lot we can do about it, I dunno. In many ways, the real
issue is simply that we have a lot of changes. And people are _never_ as
interested in the testing part as they were in writing new code..

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik · External Since: Mar 05, 2006 Posts: 1439

Andrew Morton wrote:
> If you think that shortening the release cycle will cause people to be more
> disciplined in their changes, to spend less time going berzerk and to spend
> more time working with our users and testers on known bugs then I'm all
> ears.

Honestly, I do think it would be positive. It would shorten the
feedback loop, and get more changes out to testers.

It would also decrease the pressure of the 60+ trees trying to get
everything in, because they know the next release is 3-4 months away.
It would be _much_ easier to say "break the generic device stuff in
2.6.20 not 2.6.19, please" if we knew 2.6.20 wasn't going to be a 2007
release.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton · External Since: Aug 22, 2004 Posts: 2442

On Thu, 21 Sep 2006 02:36:55 -0400
Jeff Garzik <jeff.RemoveThis@garzik.org> wrote:

> Andrew Morton wrote:
> > If you think that shortening the release cycle will cause people to be more
> > disciplined in their changes, to spend less time going berzerk and to spend
> > more time working with our users and testers on known bugs then I'm all
> > ears.
>
> Honestly, I do think it would be positive. It would shorten the
> feedback loop, and get more changes out to testers.
>
> It would also decrease the pressure of the 60+ trees trying to get
> everything in, because they know the next release is 3-4 months away.
> It would be _much_ easier to say "break the generic device stuff in
> 2.6.20 not 2.6.19, please" if we knew 2.6.20 wasn't going to be a 2007
> release.
>

Well, it might be worth trying. But there's a practical problem: how do we
get there when there's so much work pending? If we skip some people's
trees then they'll get sore, and it's not obvious that it'll help much, as
the various trees are fairly unrelated (ie: parallelisable).

I guess the most practical way is to incrementally shorten the cycles.

<rerererepeating self>

I do think that any process change we make should send the signal "slow
down, be more careful, test and review it more carefully". Or at least,
"try to make sure it compiles".

A compulsory Reviewed-by: would wedge things up nicely Wink

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox · External Since: Sep 11, 2004 Posts: 1494

Ar Mer, 2006-09-20 am 22:23 -0700, ysgrifennodd Linus Torvalds:
>
> On Wed, 20 Sep 2006, Andrew Morton wrote:
> >
> > Why would a shorter cycle be better? What are we trying to achieve?
>
> I don't think a shorter cycle is necessarily better, but I think we could
> try having a more "directed" cycle, and perhaps merge certain specific
> things rather than everything.

Works for me. We do need to keep pushing drivers each cycle (and we need
faster cycles just to keep up with the chipset people) but a situation
where people are told to keep those driver updates working with the old
core code would be fine (ie as 2.4 sometimes was) for some of the cycles
when they are not the goal.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox · External Since: Sep 11, 2004 Posts: 1494

> If you think that shortening the release cycle will cause people to be more
> disciplined in their changes, to spend less time going berzerk and to spend
> more time working with our users and testers on known bugs then I'm all
> ears.

A suggestion from the department of evil ideas: Call even cycles
development odd ones stabilizing. Nothing gets into an odd one without a
review and linux-kernel signoff/ack ?

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Roman Zippel · External Since: Aug 19, 2004 Posts: 405

Hi,

On Wed, 20 Sep 2006, john stultz wrote:

> No objections here, but I wanted to put forth some caution as I've seen
> some odd NTP behavior with the full NTP patchset on my laptop (either it
> does not converge or it just converges *much* more slowly then without).
> Unfortunately I've not been able to collect solid enough data to analyze
> the issue (really, each run should go for atleast a full day and always
> run on the same network).

grumble...
As I said before it's expected that the initial covergence is slower and I
need the data over multiple days to really say something about it.
There has been really a lot of time for doing this...

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jan Engelhardt · External Since: Jun 24, 2004 Posts: 1116

>> If you think that shortening the release cycle will cause people to be more
>> disciplined in their changes, to spend less time going berzerk and to spend
>> more time working with our users and testers on known bugs then I'm all
>> ears.
>
>A suggestion from the department of evil ideas: Call even cycles
>development odd ones stabilizing. Nothing gets into an odd one without a
>review and linux-kernel signoff/ack ?

Why, just open 2.7.0. Harhar!

Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Rafael J. Wysocki · External Since: May 20, 2006 Posts: 1156

On Thursday, 21 September 2006 08:48, Andrew Morton wrote:
> On Thu, 21 Sep 2006 02:36:55 -0400
> Jeff Garzik <jeff DeleteThis @garzik.org> wrote:
>
> > Andrew Morton wrote:
> > > If you think that shortening the release cycle will cause people to be more
> > > disciplined in their changes, to spend less time going berzerk and to spend
> > > more time working with our users and testers on known bugs then I'm all
> > > ears.
> >
> > Honestly, I do think it would be positive. It would shorten the
> > feedback loop, and get more changes out to testers.
> >
> > It would also decrease the pressure of the 60+ trees trying to get
> > everything in, because they know the next release is 3-4 months away.
> > It would be _much_ easier to say "break the generic device stuff in
> > 2.6.20 not 2.6.19, please" if we knew 2.6.20 wasn't going to be a 2007
> > release.
> >
>
> Well, it might be worth trying. But there's a practical problem: how do we
> get there when there's so much work pending? If we skip some people's
> trees then they'll get sore, and it's not obvious that it'll help much, as
> the various trees are fairly unrelated (ie: parallelisable).
>
> I guess the most practical way is to incrementally shorten the cycles.
>
>
> <rerererepeating self>
>
> I do think that any process change we make should send the signal "slow
> down, be more careful, test and review it more carefully". Or at least,
> "try to make sure it compiles".
>
> A compulsory Reviewed-by: would wedge things up nicely Wink

Well, I think this need not help. Like when some USB-related changes that
had been reviewed and even tested happened to break ohci-hcd because they
had only been tested on uhci ...

IMHO every change should appear in at least three consecutive -mm kernels
without causing any problems before it's allowed to go to the mainline.

Greetings,
Rafael

--
You never change things by fighting the existing reality.
R. Buckminster Fuller
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Ingo Molnar · External Since: May 15, 2006 Posts: 2457

* Andrew Morton <akpm DeleteThis @osdl.org> wrote:

> ntp-move-all-the-ntp-related-code-to-ntpc.patch
> ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch
> ntp-add-ntp_update_frequency.patch
> ntp-add-ntp_update_frequency-fix.patch
> ntp-add-time_adj-to-tick-length.patch
> ntp-add-time_freq-to-tick-length.patch
> ntp-prescale-time_offset.patch
> ntp-add-time_adjust-to-tick-length.patch
> ntp-remove-time_tolerance.patch
> ntp-convert-time_freq-to-nsec-value.patch
> ntp-convert-to-the-ntp4-reference-model.patch
> ntp-cleanup-defines-and-comments.patch
> kernel-time-ntpc-possible-cleanups.patch
> kill-wall_jiffies.patch
>
> Will merge.

would be nice to merge the -hrt queue that goes right ontop this queue.
Even if HIGH_RES_TIMERS is "default n" in the beginning. That gives us
high-res timers and dynticks which are both very important features to
certain classes of users/devices.

The current queue is at:

http://tglx.de/projects/hrtimers/2.6.18/

Hm?

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Michael Hanselmann · External Since: Dec 06, 2005 Posts: 17

On Wed, Sep 20, 2006 at 01:54:38PM -0700, Andrew Morton wrote:
> apple-motion-sensor-driver-2.patch
> apple-motion-sensor-driver-2-fixes-update.patch
> apple-motion-sensor-driver-kconfig-fix.patch

Please wait with those. We're currently trying to come up with a generic
class for all motion sensor drivers in the kernel. This will change the
userland interface again.

Thanks,
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linus Torvalds · External Since: Jan 12, 2005 Posts: 517

On Thu, 21 Sep 2006, Alan Cox wrote:
>
> A suggestion from the department of evil ideas: Call even cycles
> development odd ones stabilizing. Nothing gets into an odd one without a
> review and linux-kernel signoff/ack ?

I don't think that's an evil idea, and in fact we've discussed it before.
I personally like it - right now we tend to have that "interminable series
of -rc<n>" (where <n> is 3..) before release, and I'd almost personally
prefer to just have a rule that is more along the lines of

- 2.6.<odd> is "the big initial merges with all the obvious fixes to make
it all work" (ie roughly the current -rc2 or perhaps -rc3).

- 2.6.<even> is "no big merges, just careful fixes" (ie the current "real
release")

Each would be ~3 weeks, leaving us with effectively the same real release
schedule, just a naming change.

That said, I think Andrew was of the opinion that it doesn't really _fix_
anything, and he may well be right. What's the point of the odd release,
if the weekly snapshots after that are supposed to be strictly better than
it anyway?

So I think I may like it just because it _seems_ to combine the good
features of both the old naming scheme and the current one, but I suspect
Andrew may be right in that it doesn't _really_ change anything, deep
down.

Dunno.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Christoph Lameter · External Since: Sep 29, 2006 Posts: 1367

On Wed, 20 Sep 2006, Martin J. Bligh wrote:

> > ZONE_DMA is only used as ZONE_NORMAL if the architecture does not need
> > ZONE_NORMAL because all of memory is reachable via DMA.
>
> That's still inconsistent because it doesn't say DMA for *which*
> device.

Thats the way ZONE_DMA works right now and AFAIK the only way forward is
to make it optional and then introduce another way of allocating memory
for a device. The migrate away from it. The first step is to allow people
who do not need ZONE_DMA to opt out.

> > That wont work because many architectures use different limits. Maybe you
> > should once in a while have a look at the sources.
>
> I'm perfectly well aware that it's inconsistent, that's my whole point.
> However, by some chance of history, it's sort of vaguely working. I
> think it's dangerous to mess with it rather than fixing it properly.

I think you are spreading FUD. The existing scheme has been working for a
long time. Come up with something concrete. I am not
changing the definition of ZONE_DMA.

> AFAICS, the correct way to do this is have the requestor pass a memory
> bound into the allocator, and have the arch figure out which zones
> are applicable.

Exactly. But you cannot do that with ZONE_DMA __GFP_DMA. We likely need a
new page allocator API for that.

> > Actually the desaster is cleaned up by this patch. A couple of architectures
> > that were wrongly using ZONE_DMA now use ZONE_NORMAL.
>
> Odd that the PPC64 maintainers didn't seem to know about this.
> Perhaps it might be a good idea to talk to them before doing this?

Maybe they have not been reading linux-arch? It was discussed among arch
maintainers and 4 arches have switched off ZONE_DMA for good.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jan Engelhardt · External Since: Jun 24, 2004 Posts: 1116

On Sep 21 2006 08:25, Linus Torvalds wrote:
>
> - 2.6.<odd> is "the big initial merges with all the obvious fixes to make
> it all work" (ie roughly the current -rc2 or perhaps -rc3).
>
> - 2.6.<even> is "no big merges, just careful fixes" (ie the current "real
> release")

That sounds interesting. To me this looks like a careful approach at
more or less marking a release "this contains new stuff" and "this does
not", like 2.<odd>.x and 2.<even>.x, respectively, but of course without
the code divergence that happened between 2.4 and 2.5.

Will there be a -stable branch for 2.6.<odd>s, or will they be limited
to 2.6.<even>, just like there is no -stable for -rcs?

>Each would be ~3 weeks, leaving us with effectively the same real release
>schedule, just a naming change.

More or less, yes. Let's assume a "good release" (one with a fair number
of -rcs), and compare both approches (hope your MUA does tabs= Cool

:

Week/Current Current style Week/Proposal Your proposal
+0 2.6.18 +0 2.6.18
+2 2.6.19-rc1 - none
+3 2.6.19-rc2 +3 2.6.19
+4 2.6.19-rc3 - none
+5 2.6.19 +6 2.6.20
+7 2.6.20-rc1 - none
+8 2.6.20-rc2 +9 2.6.21
+9 2.6.20-rc3 - none
+10 2.6.21 +12 2.6.22
(+1 between each -rc is purely assumptional)

Though this is a purely dry mathematical table. We did not always stick
to a "-rc3 at most" rule, but gone up to like -rc7 recently. With the
new versioning scheme, no such thing seems likely to be happening
(excluding of course external influences like people travelling).
IOW, the schedule gets more organized. I like that idea.

(Based upon the assumption that 1 week passes between each -rc
release, there would, with the new proposal, 'only' be 243 weeks to hit
2.6.99 instead of 405. That is, version numbers go up faster Smile

Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

James Bottomley · External Since: Jun 17, 2005 Posts: 252

On Thu, 2006-09-21 at 02:03 +0100, Alan Cox wrote:
> IOMMUs don't always help. They IOMMU aperture on AMD64 for example is
> too high to help devices with below 32bit limits.

That's because it's not an IOMMU; it's a GART. A true IOMMU separates
the machine physical and bus physical address spaces ... a GART merely
remaps a hole in physical address space.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Martin Bligh · External Since: May 15, 2006 Posts: 40

Christoph Lameter wrote:
> On Wed, 20 Sep 2006, Martin J. Bligh wrote:
>
>
>>>ZONE_DMA is only used as ZONE_NORMAL if the architecture does not need
>>>ZONE_NORMAL because all of memory is reachable via DMA.
>>
>>That's still inconsistent because it doesn't say DMA for *which*
>>device.
>
>
> Thats the way ZONE_DMA works right now and AFAIK the only way forward is
> to make it optional and then introduce another way of allocating memory
> for a device. The migrate away from it. The first step is to allow people
> who do not need ZONE_DMA to opt out.

OK. Let's leave aside the issue for a second of whether ZONE_DMA should
be configurable or not (ie your patch), and just worry about how this
works in practice going forwards in the short term. Don't get me wrong,
I'd love to kill ZONE_DMA, or at least the 16MB way it's implemented in
i386 right now.

I presume the fallback order for everything is still
HIGHMEM -> NORMAL -> DMA, and nobody is proposing changing that.
(ignoring DMA32 to keep thing simpler).

If a device driver wants "DMAable" memory, and thus does a ZONE_DMA
allocation, and we've moved all its memory from ZONE_DMA to ZONE_NORMAL
(as I think you're proposing doing for PPC64 (and ia64?)), then the
allocation will fail.

So are we saying that no driver code should be calling with GFP_DMA
(a quick grep turns up 148 instances under driver/), that if they do
they should only work on specific architectures (some instances were
s390-only drivers)? If so, should we not be removing the definiton of
GFP_DMA itself if ZONE_DMA is config'ed out, so that it fails at
compile time, rather than runtime?

>>AFAICS, the correct way to do this is have the requestor pass a memory
>>bound into the allocator, and have the arch figure out which zones
>>are applicable.
>
> Exactly. But you cannot do that with ZONE_DMA __GFP_DMA. We likely need a
> new page allocator API for that.

Glad we're agreed on that, at least.

M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton · External Since: Aug 22, 2004 Posts: 2442

On Thu, 21 Sep 2006 15:14:33 +0200
Ingo Molnar <mingo.TakeThisOut@elte.hu> wrote:

>
> * Andrew Morton <akpm.TakeThisOut@osdl.org> wrote:
>
> > ntp-move-all-the-ntp-related-code-to-ntpc.patch
> > ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch
> > ntp-add-ntp_update_frequency.patch
> > ntp-add-ntp_update_frequency-fix.patch
> > ntp-add-time_adj-to-tick-length.patch
> > ntp-add-time_freq-to-tick-length.patch
> > ntp-prescale-time_offset.patch
> > ntp-add-time_adjust-to-tick-length.patch
> > ntp-remove-time_tolerance.patch
> > ntp-convert-time_freq-to-nsec-value.patch
> > ntp-convert-to-the-ntp4-reference-model.patch
> > ntp-cleanup-defines-and-comments.patch
> > kernel-time-ntpc-possible-cleanups.patch
> > kill-wall_jiffies.patch
> >
> > Will merge.
>
> would be nice to merge the -hrt queue that goes right ontop this queue.
> Even if HIGH_RES_TIMERS is "default n" in the beginning. That gives us
> high-res timers and dynticks which are both very important features to
> certain classes of users/devices.
>
> The current queue is at:
>
> http://tglx.de/projects/hrtimers/2.6.18/
>

I've never even looked at this work. Just add it to the pipeline I guess.
We can merge it once it passes review by Roman Wink

But the possible problems with the NTP patches which John has possibly
observed were news to me - it's not clear what the situation is there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Christoph Lameter · External Since: Sep 29, 2006 Posts: 1367

On Thu, 21 Sep 2006, Martin Bligh wrote:

> I presume the fallback order for everything is still
> HIGHMEM -> NORMAL -> DMA, and nobody is proposing changing that.
> (ignoring DMA32 to keep thing simpler).

It would help if you would actually look at the code instead of presuming.
No changes are made in that area.

> If a device driver wants "DMAable" memory, and thus does a ZONE_DMA
> allocation, and we've moved all its memory from ZONE_DMA to ZONE_NORMAL
> (as I think you're proposing doing for PPC64 (and ia64?)), then the
> allocation will fail.

I would not presume proposing anything for PPC64 and left everything the
way it is. The arch people can control if they want ZONE DMA or not and
the default is to leave things as is. If PPC64 wants to go ZONE_DMAless
then the arch code needs to be modified not refer to ZONE_DMA anymore and
if that works then we can switch CONFIG_ZONE_DMA off for PPC64. See the
patches in mm for examples how other arches have done it.

> So are we saying that no driver code should be calling with GFP_DMA
> (a quick grep turns up 148 instances under driver/), that if they do
> they should only work on specific architectures (some instances were
> s390-only drivers)? If so, should we not be removing the definiton of
> GFP_DMA itself if ZONE_DMA is config'ed out, so that it fails at
> compile time, rather than runtime?

This was covered at length before. Removing all GFP_DMA references would
require extensive #ifdefs. The limited patch in mm is only neutering
GFP_DMA for arches that do not need it. If an arch has removed its definition of
CONFIG_ZONE_DMA then __GFP_DMA will be ignored in the page allocator.

> > > AFAICS, the correct way to do this is have the requestor pass a memory
> > > bound into the allocator, and have the arch figure out which zones
> > > are applicable.
> >
> > Exactly. But you cannot do that with ZONE_DMA __GFP_DMA. We likely need a
> > new page allocator API for that.
>
> Glad we're agreed on that, at least.

I think we agree on a lot more. Hopefully when we meet at lunch today we
can sync some more.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton · External Since: Aug 22, 2004 Posts: 2442

On Thu, 21 Sep 2006 08:25:55 -0700 (PDT)
Linus Torvalds <torvalds.TakeThisOut@osdl.org> wrote:

>
>
> On Thu, 21 Sep 2006, Alan Cox wrote:
> >
> > A suggestion from the department of evil ideas: Call even cycles
> > development odd ones stabilizing. Nothing gets into an odd one without a
> > review and linux-kernel signoff/ack ?
>
> I don't think that's an evil idea, and in fact we've discussed it before.
> I personally like it - right now we tend to have that "interminable series
> of -rc<n>" (where <n> is 3..) before release, and I'd almost personally
> prefer to just have a rule that is more along the lines of
>
> - 2.6.<odd> is "the big initial merges with all the obvious fixes to make
> it all work" (ie roughly the current -rc2 or perhaps -rc3).
>
> - 2.6.<even> is "no big merges, just careful fixes" (ie the current "real
> release")
>
> Each would be ~3 weeks, leaving us with effectively the same real release
> schedule, just a naming change.
>
> That said, I think Andrew was of the opinion that it doesn't really _fix_
> anything, and he may well be right. What's the point of the odd release,
> if the weekly snapshots after that are supposed to be strictly better than
> it anyway?
>
> So I think I may like it just because it _seems_ to combine the good
> features of both the old naming scheme and the current one, but I suspect
> Andrew may be right in that it doesn't _really_ change anything, deep
> down.
>

Again, before we can implement anything we should describe what problem we are
actually trying to solve here.

Jeff: "I want faster release cycles because <no reason given>"

Me: "I want less bugs"

Anyone else?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik · External Since: Mar 05, 2006 Posts: 1439

Andrew Morton wrote:
> Jeff: "I want faster release cycles because <no reason given>"

All the standard goodness that "release early, release often" provides.

* Avoiding the achingly long wait where huge amounts of changes pile up,
then go in. It should be OBVIOUS that
merge 10,000 changes. global test. repeat
is worse than
merge 1,000 changes. global test. repeat.

I think it's patently unfair to complain about bugs and regressions,
then limit developers to 3-4 test points [mainline releases] per year.

* Faster release cycles means code doesn't spend a quarter of the year
in limbo before users test it and give good feedback.

* Code stands a better chance of getting more review.

* Regressions are perceived to be fixed more quickly, if the fix
requires more than just 1-2 lines going to stable RemoveThis @kernel.org.

* Submitters don't have to wait for a quarter of a year in order for
their submissions to hit a mainline release.

With this last release, I just didn't see the value at all to going all
the way to -rc7. There weren't huge numbers of testers screaming about
-rc1 and -rc2. It just seemed like we delayed for no good reason other
than a blind hope that the passage of time would fix bugs.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/