linux-kernel - Re: PING? cleancache for 2.6.39 window?

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>] [day] [month] [year] [list]

Date:	Thu, 24 Feb 2011 19:50:58 +0000
From:	Matt <jackdachef@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux-mm <linux-mm@...r.kernel.org>
Subject: Re: PING? cleancache for 2.6.39 window?

>Hi Andrew (and Linus) --

>As you may have seen, gregkh has taken zcache into drivers/staging
>for merging when the 2.6.39 window opens.  And zcache (which
>works entirely in-kernel, no virtualization required) depends on
>cleancache.

>Cleancache and zcache are both in linux-next and, via linux-next,
>in mmotm.  Last October, Linus said that he preferred cleancache
>to merge via you (Andrew), not pulled from my git tree.  So:

>1) Is cleancache finally now acceptable for merging in the
>   upcoming 2.6.39 window? and
>2) If so, is there anything else I need to do to ensure the
>   merging of cleancache happens during the open window or will
>   it all happen automagically (from my point of view) through
>   your (Andrew's) normal open-window processes?

>Sorry to be excessively persistent, but I don't want to miss
>the 2.6.39 window due to my newbie-ness.  And I plan to be on
>vacation for some time during March and would also like to ensure
>I don't miss something *I* need to do before or during the
>window.

>Thanks,
>Dan Magenheimer

Hi Linus, Hi Andrew,

Hi Dan,

will this get into 2.6.39 ?

It's been running  fine for me now with 2.6.37 for some time and I
have to say that it definitely cuts latencies & time needed to work

under higher memory or cpu pressure workloads (e.g. rsyncing while
compiling big programs such as libreoffice or chromium and listening
to audio at the same time) with the added bonus of less swapping and
memory consumption of the filesystem pagecache.

I haven't seen any problems so far with ext4,

btrfs very probably also will work fine in the near future (the umount
problem with btrfs I've noticed & reported is currently under
investigation & a fix on the way).

So there's no data-eating or other real problem right now that might
seriously hinder further widespread testing ;)

Getting this into mainline staging and the willingness of filesystem
developers provided - there could also be the possibility to add
support for XFS and other filesystems - making fast & excellent
filesystems (and workloads) even more efficient :)


I don't know if it's already under consideration or in linux-next but
the "zram_xvmalloc: 64K page fixes and optimizations" (which I'm
currently testing with zcache) might improve things even more.


Thanks for your consideration & Regards

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