And the Great And Powerful Linus replied:
> Ehh. And in the process completely breaking the whole "current" macro.
> You'd speed up one small thing only to slow down everything else.
> Hardware is getting better all the time. The time when direct-mapped or
> even two-way mapped caches were de rigeur are long gone.
I see more 4-way associatve L1 caches (mostly because keeping
the way size of a cache to a page makes life easier for the hardware),
but I don't see associativity growing explosively any time soon.
In particular, I don't see way sizes dropping below a 4K page
any time soon, and by page-aligning the structures, you're
limiting yourself to 1% of the cache. Which hurts no matter what the
cache organization.
This was discussed a few months ago, and does not break the current
macro. You keep a pointer to the task struct on top of the stack,
but not the whole task struct. This adds a cached memory reference
(you *did* just enter kernel state and pushed stuff onto the stack,
didn't you?) to the current macro, but nothing hideous.
You may recall that this idea came up when discussing the problem of
forks failing when unable to allocate two aligned pages even if the
kernel had lots of single pages. It was proposed as a way to leep the
efficiency of the current macro while reducing the kernel stack back to
a single page.
-- -Colin- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/