From: "michael chang" <thenewme91@gmail.com>
To: "Con Kolivas" <kernel@kolivas.org>
Cc: "ck mailing list" <ck@vds.kolivas.org>,
"linux kernel mailing list" <linux-kernel@vger.kernel.org>
Subject: Re: [ck] Re: 2.6.20-ck1
Date: Sat, 17 Feb 2007 12:28:43 -0500 [thread overview]
Message-ID: <b14e81f00702170928y5c2d3e2es14917c93049064e8@mail.gmail.com> (raw)
In-Reply-To: <200702171417.28376.kernel@kolivas.org>
On 2/16/07, Con Kolivas <kernel@kolivas.org> wrote:
> On Saturday 17 February 2007 13:15, michael chang wrote:
> > On 2/16/07, Con Kolivas <kernel@kolivas.org> wrote:
> > > I'm thru with bashing my head against the wall.
> >
> > I do hope this post isn't in any way redundant, but from what I can
> > see, this has never been suggested... (someone please do enlighten me
> > if I'm wrong.)
> >
> > Has anyone tried booting a kernel with the various patches in question
> > with a mem=###M boot flag (maybe mem=96M or some other "insanely low
> > number" ?) to make the kernel think it has less memory than is
> > physically available (and then compare to vanilla with the same
> > flags)? It might more clearly demonstrate the effects of Con's patches
> > when the kernel thinks (or knows) it has relatively little memory
> > (since many critics, from what I can tell, have quite a bit of memory
> > on their systems for their workloads).
> >
> > Just my two cents.
>
> Oh that's not a bad idea of course. I've been testing it like that for ages,
It never hurts to point out the obvious in case someone didn't notice,
so long as one doesn't become repetitive.
> and there are many -ck users who have testified to swap prefetch helping in
> low memory situations for real as well. Now how do you turn those testimonies
> into convincing arguments? Maintainers are far too busy off testing code for
> 16+ cpus, petabytes of disk storage and so on to try it for themselves. Plus
Pity. What about virtualization? Surely one of these 16+ CPU machines
with petabytes of disk storage can spare one CPU for an hour for a
virtual machine, just set it with like a 3 GB hard drive image (which
is later deleted), 1 GB swap (ditto), 128 MB memory, and one CPU
instance -- then test with vanilla and the patches in question? (My
understanding is that one of the major "fun things" that these kinds
of machines have is that they come with interesting VM features and
instruction sets.)
> they worry incessantly that my patches may harm those precious machines'
> performance...
Has anyone tested it on one of these massive multi-core "beasts" and
seen if it DOES degrade performance? I want to see numbers. Since the
performance improvements for these machines are based on numbers, I
want to see any argument for degradation also in numbers. Both
absolute numbers and relative numbers.
(Obviously, since -ck doesn't target that kind of thing, it's not
possible at the moment to prove how useful -ck is with numbers. But
surely we can measure how much of a "negative" impact it does have on
everything else. If it isn't hurting anyone, then what's wrong with
it?)
Unfortunately, the argument that "xyz" is just as bad/worse is hardly
useful from what I've seen in kernel talks... maybe we're missing
something here.
Is it possible to command a program's memory usage be put into swap on
purpose, without "forcing" it into swap by taking other memory? (Maybe
such a feature could be used to time how long it takes to restore from
swap by timing how long the first or second display update takes on
some typically-used GUI program that takes a while to draw its GUI.)
Just a couple of additional thoughts.
> --
> -ck
>
--
~Mike
- Just the crazy copy cat.
P.S. For anyone who cares and is sending replies to my messages, I am
subscribed to the ck ML, but not linux-kernel. So if you want me to
see it and it's in the latter, CC me.
next prev parent reply other threads:[~2007-02-17 17:28 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-16 10:10 2.6.20-ck1 Con Kolivas
2007-02-16 15:47 ` 2.6.20-ck1 Malte Schröder
2007-02-16 21:35 ` 2.6.20-ck1 Edouard Gomez
2007-02-16 21:45 ` 2.6.20-ck1 Edouard Gomez
2007-02-17 0:53 ` 2.6.20-ck1 Chuck Ebbert
2007-02-17 1:13 ` 2.6.20-ck1 Con Kolivas
2007-02-17 2:15 ` [ck] 2.6.20-ck1 michael chang
2007-02-17 3:17 ` Con Kolivas
2007-02-17 17:28 ` michael chang [this message]
2007-02-17 18:45 ` Chuck Ebbert
2007-02-17 21:00 ` Con Kolivas
2007-02-17 21:50 ` michael chang
2007-02-17 23:47 ` Andrew Morton
2007-02-18 0:39 ` 2.6.20-ck1 Con Kolivas
2007-02-18 0:41 ` [ck] 2.6.20-ck1 Radoslaw Szkodzinski
2007-02-18 0:45 ` 2.6.20-ck1 Con Kolivas
2007-02-17 11:15 ` 2.6.20-ck1 Hugo Vanwoerkom
2007-02-18 2:14 ` 2.6.20-ck1 mdew .
2007-02-18 2:38 ` 2.6.20-ck1 Con Kolivas
2007-02-18 6:05 ` [ck] 2.6.20-ck1 Con Kolivas
2007-02-18 6:15 ` Rodney Gordon II
2007-02-18 6:20 ` Rodney Gordon II
2007-02-18 16:54 ` 2.6.20-ck1 Ryan M.
2007-02-18 19:00 ` [ck] 2.6.20-ck1 Ash Milsted
2007-02-24 12:12 ` 2.6.20-ck1 Fabio Comolli
2007-02-25 4:34 ` 2.6.20-ck1 Gene Heskett
2007-02-25 10:32 ` 2.6.20-ck1 Con Kolivas
2007-02-25 16:33 ` 2.6.20-ck1 Gene Heskett
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=b14e81f00702170928y5c2d3e2es14917c93049064e8@mail.gmail.com \
--to=thenewme91@gmail.com \
--cc=ck@vds.kolivas.org \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®