Messages in this thread | | | Date | Tue, 08 Jun 2004 10:03:20 +0200 | From | Zoltan Menyhart <> | Subject | Re: Who owns those locks ? |
| |
Bjorn Helgaas wrote: > > There are a couple issues I was thinking of when > I wrote "clean it up, pull the bits together...": > > 1) Tony Luck's question about what happens when > "shr.u r30 = r13, 12" yields zero in the 32-bit > lock value. I'm not the 2.6 maintainer, but I'd > sure like to see some solution for this. It would > be a nightmare to debug a system where one random > task didn't release locks correctly. Since other > arches use a trick like this, I'm hoping they've > figured out something we can copy (I haven't looked).
Sure, I did not want to make an error like saying: "640 K ought to be enough for everyone".
I'm afraid, there is no perfect solution.
- We do not want to change the lock size to 64 bits, do we ? -- Couple of new alignment problems.
- You keep my code, it is correct for a memory size up to 16 Tbytes.
- You shift by PAGE_SHIFT, rather than by 12 (using page size of 16 Kbytes) => up to 64 Tbytes. -- Not that much human readable lock values.
- You move to PAGE_SIZE = 64 K, you get human readable lock values up to 256 Tbytes.
- You could store the "PID | miraculous bit" (to avoid PID = 0 problem). -- Somewhat longer code.
I expect the main stream IA64 kernel to move to PAGE_SIZE = 64 K by the time there will be machines with more than 16 Tbytes of memory (as the processors have got just a very limited number of translation look aside buffer entries, and the ever growing application / memory sizes result in higher TLB miss rate unless the page size increases).
Regards,
Zoltán - 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/
| |