Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [discuss] Re: [1/3] Add 4GB DMA32 zone | Date | Tue, 13 Sep 2005 11:47:41 +0200 |
| |
On Tuesday 13 September 2005 11:15, Roman Zippel wrote: > Hi, > > On Mon, 12 Sep 2005, Andi Kleen wrote: > > > On Sun, 11 Sep 2005, Andi Kleen wrote: > > > > -#define MAX_NR_ZONES 3 /* Sync this with ZONES_SHIFT */ > > > > -#define ZONES_SHIFT 2 /* ceil(log2(MAX_NR_ZONES)) */ > > > > +#define MAX_NR_ZONES 4 /* Sync this with ZONES_SHIFT */ > > > > +#define ZONES_SHIFT 3 /* ceil(log2(MAX_NR_ZONES)) */ > > > > > > Why needs ZONES_SHIFT to be increased? > > > > > > > -#define FLAGS_RESERVED 8 > > > > +#define FLAGS_RESERVED 9 > > > > > > I would prefer to keep this at 8. > > > > sparsemem needs these two. > > Did I somehow offend you, that I don't deserve an answer?
Well, your aggressive tone definitely doesn't encourage speedy answers.
> The reason for my question is rather simple (and I thought obvious), the > four zone types fit into two bits, so what is sparsemem doing with this > extra bit?
iirc it was a patch that came in over Andrew. I can't find the email anymore unfortunately. The argument looked plausible and I think it fixed a boot problem for the submitter on some arch (probably IA64, on x86-64 it worked fine without it, but I've never tried sparsemem and the code was originally written before sparsemem). Andrew do you still have the patch with the description? It must have been between 2.6.13mm1 and 2.6.13mm2.
You're right that four zones should in theory fit into 2 bits, so I'm also not sure why it was needed.
-Andi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |