On Wed, 25 Apr 2007, Eric W. Biederman wrote:
> You are trying to couple something that has no business being coupled
> as it reduces the system usability when you couple them.
What I am coupling? The approach solves a series of issues as far as I can
tell.
> > But that is due to the VM (at least Linus tree) having no defrag methods.
> > mm has Mel's antifrag methods and can do it.
>
> This is fundamental. Fragmentation when you multiple chunk sizes
> cannot be solved without a the ability to move things in memory,
> whereas it doesn't exist when you only have a single chunk size.
We have that ability (although in a limited form) right now.
> > Yes you get lots of small request *because* we do not support defrag and
> > cannot large contiguous allocations.
>
> Lots of small requests are fundamental. If lots of small requests were
> not fundamental we would gets large requests scatter gather requests.
That is a statement of faith in small requests? Small requests are
fundamental so we want them?
> > Ummm the other arches read 16k blocks of contigous memory. That is not
> > supported on 4k platforms right now. I guess you you move those to vmalloc
> > areas? Want to hack the filesystems for this?
>
> Freak no. You teach the code how to have a block in multiple physical
> pages.
This aint gonna work without something that stores the information about
how the pieces come together. Teach the code.... More hacks.
> > There are multiple scaling issues in the kernel. What you propose is to
> > add hack over hack into the VM to avoid having to deal with
> > defragmentation. That in turn will cause churn with hardware etc
> > etc.
>
> No. I propose to avoid all designs that have the concept of
> fragmentation.
There are such designs? You can limit fragmentation but not avoid it.
> There is an argument for having struct page control more than 4K
> of memory even when the hardware page size is 4K. But that is a
> separate problem. And by only having one size we still don't
> get fragmentation.
We have fragmentation because we cannot limit our allocation sizes to 4k.
The stack is already 8k and there are subsystems that need more (f.e.
for jumbo frames). Then there is the huge page subsystem that is used to
avoid the TLB pressure that comes with small pages.
I think we are doing our typical community thing of running away from the
problem and developing ways to explain why our traditional approaches are
right.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
