linux-kernel - RE: cleancache can lead to serious performance degradation

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

Date:	Mon, 29 Aug 2011 08:08:32 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Nebojsa Trpkovic <trx.lists@...il.com>
Cc:	linux-kernel@...r.kernel.org, Konrad Wilk <konrad.wilk@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	Nitin Gupta <ngupta@...are.org>
Subject: RE: cleancache can lead to serious performance degradation

> From: Nebojsa Trpkovic [mailto:trx.lists@...il.com]
> Subject: Re: cleancache can lead to serious performance degradation
> 
> Thank you everybody for reviewing my report.

Thanks for reporting it!  To paraphrase Clint Eastwood:

"A kernel developer's got to know his patchset's limitations".

(Clint said "A man's got to know his limitations" in Magnum Force, 1973.)

> I've noticed performance degradation during the real workload. I did not
> run any special benchmarks to prove this problem. All my conclusions are
> based on everyday usage case scenarios.
> 
> I use multi-purpose (read: all-purpose) server with Intel Core 2 Duo
> E6550, 8GB DDR2, 4 1Gbps NICs and 16 1.5TB 5.4k rpm hard drives in LAN
> with ~50 workstations and WAN with couple of hundreds clients.

<snip>

OK, so the old CPU is mostly acting as a fancy router between 16 spindles
and 4 fast NICs to transfer very large "packets" (sequential files).
I can see how that kind of workload would not be kind to zcache,
though a more modern multi-core (4-core i7?) might handle it better.
And, as suggested earlier in this thread, a faster-but-less-space-efficient
compression algorithm would be useful too, along with some policy
that senses when 

> Last but not least, thank you for developing such a great feature for
> Linux kernel!

Thanks!  Many people contributed (especially Nitin Gupta).  I hope other
users and workloads have better luck with it than you/yours does!

> Best Regards,
> Nebojsa Trpkovic

Thanks,
Dan
--
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/