From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Nebojsa Trpkovic <trx.lists@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Konrad Wilk <konrad.wilk@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Seth Jennings <sjenning@linux.vnet.ibm.com>,
Nitin Gupta <ngupta@vflare.org>
Subject: RE: cleancache can lead to serious performance degradation
Date: Mon, 29 Aug 2011 08:08:32 -0700 (PDT) [thread overview]
Message-ID: <4724822e-3798-4837-aba3-e87d191bd40e@default> (raw)
In-Reply-To: <4E5AE138.20408@gmail.com>
> From: Nebojsa Trpkovic [mailto:trx.lists@gmail.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
prev parent reply other threads:[~2011-08-29 15:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-17 21:57 cleancache can lead to serious performance degradation Nebojsa Trpkovic
2011-08-25 4:12 ` Konrad Rzeszutek Wilk
2011-08-25 16:56 ` Dan Magenheimer
2011-08-26 13:24 ` Seth Jennings
2011-08-26 14:42 ` Dan Magenheimer
2011-08-29 0:45 ` Nebojsa Trpkovic
2011-08-29 15:08 ` Dan Magenheimer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4724822e-3798-4837-aba3-e87d191bd40e@default \
--to=dan.magenheimer@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ngupta@vflare.org \
--cc=sjenning@linux.vnet.ibm.com \
--cc=trx.lists@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.