linux-kernel - Re: [PATCH] Optimize relay_alloc_page_array() slightly by using vzalloc rather than vmalloc and memset

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: <4CCEC3B9.1060703@kernel.dk>
Date:	Mon, 01 Nov 2010 09:42:17 -0400
From:	Jens Axboe <axboe@...nel.dk>
To:	Pekka Enberg <penberg@...nel.org>
CC:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Jesper Juhl <jj@...osbits.net>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tom Zanussi <zanussi@...ibm.com>,
	Karim Yaghmour <karim@...rsys.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] Optimize relay_alloc_page_array() slightly by using 
 vzalloc rather than vmalloc and memset

On 2010-11-01 09:41, Pekka Enberg wrote:
> * Jens Axboe (axboe@...nel.dk) wrote:
>>> On 2010-10-30 17:47, Mathieu Desnoyers wrote:
>>>> BLK_DEV_IO_TRACE seems to still select RELAY. Has it completed its
>>>> transition to either Ftrace or Perf ? Depending on Jens, moving blktrace
>>>> relay dependency to the Generic Ring Buffer Library might be a good
>>>> option to consider.
>>>
>>> The blktrace user bits is still (by far) the most wide spread way that
>>> blktrace is used in the field, and those still rely on relayfs. So no,
>>> we can't kill it now.
> 
> On Mon, Nov 1, 2010 at 3:08 PM, Mathieu Desnoyers
> <mathieu.desnoyers@...ymtl.ca> wrote:
>> What I am proposing is that the Generic Ring Buffer Library could
>> replace relayfs without changing any of the interfaces blktrace exposes
>> to user-space. Indeed, I would not remove relayfs unless there was a
>> replacement.
> 
> We don't in general NAK cleanups because of future features or
> removals that may or may not happen.

Agree, this is parallel to whether or not we can transition blktrace to
using the generic ring buffer library or not. If the current patch
proposed makes sense, then it should go in regardless of
potential/future plans.

-- 
Jens Axboe

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