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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.63.0607240752050.8221@qynat.qvtvafvgr.pbz>
Date:	Mon, 24 Jul 2006 07:55:15 -0700 (PDT)
From:	David Lang <dlang@...italinsight.com>
To:	yunfeng zhang <zyf.zeroos@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: Improvement on memory subsystem

On Mon, 24 Jul 2006, yunfeng zhang wrote:

> 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.

this gets discussed periodicly, however the performance hit of doing the mapping 
for all core memory accesses is something that the developers have not been 
willing to accept.

> 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.

experiment, if it's as good as you think it will be post the numbers an you will 
get a lot of attention. quite a few people are working on the memory allocation 
for various things, therea re a lot of useage patterns to balance (and avaid 
pathalogical problems with).

David Lang
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ