linux-kernel - Re: Improvement on memory subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4df04b840607240201l19f95f8cu12dca42de71dba69@mail.gmail.com>
Date:	Mon, 24 Jul 2006 17:01:53 +0800
From:	"yunfeng zhang" <zyf.zeroos@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: Improvement on memory subsystem

How to let memory subsystem allocate bigger consecutive memory pages? In current
Linux, to driver programmer it's always failed to issue a request to alloc_pages
with a enough larger order parameter, or it's diffult to allocate a bigger
consecutive physical memory block.

The reason causing the problem, I think, are the items listed below
1) Core space has a static mapping relationship with physical memory pages. So
once a core page is allocated, its core address is also fixed, it prevents the
physical pages around it to conglomerate together.
2) Current physical page management arithmetic is buddy arithmetic. The main
advantage of its is that pages managed by it is always aligned by 2 power. But,
is it necessary or there is any hardware which need physical memory pages
aligned by 2 or more power?

The solution is
1) Using dynamic page mapping on core space. So we can move all core pages
freely anytime to conglomerate bigger consecutive memory pages, a new background
daemon thread -- RemapDaemon can do conglomeration periodly.
2) Using another page management arithmetic instead of buddy, the minimum unit
of new arithmetic should be page. In fact, I think dlmalloc arithmetic is a good
candidate, it's also page conglomeration-affinity.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/