From: "Mark A. Greer" <mgreer@mvista•com>
To: Val Henson <val@nmt•edu>
Cc: Benjamin Herrenschmidt <benh@kernel•crashing.org>,
linuxppc-dev@lists•linuxppc.org
Subject: Re: Highmem on PPC?
Date: Thu, 07 Feb 2002 16:09:14 -0700 [thread overview]
Message-ID: <3C63091A.4D9EA2D8@mvista.com> (raw)
In-Reply-To: 20020207145844.F19569@boardwalk
Val Henson wrote:
> On Thu, Feb 07, 2002 at 02:53:19PM -0700, Mark A. Greer wrote:
> >
> > Val Henson wrote:
> >
> > > Also, I don't think this was a particularly good test of highmem since
> > > I don't think many bounce buffers were used, or that the kernel had
> > > much reason to map/unmap many highmem pages. Unfortunately, my SCSI
> > > controller isn't working quite right and I can't test with a hard disk
> > > as a result. Any ideas for stressing the system harder?
> >
> > You could try lowering max_low_mem. You can do this by setting "Code
> > maturity level option"/"Prompt for advanced kernel configuration options"
> > and then going under where you selected HIGH_MEM and setting max_low_mem
> > size to something small.
> >
> > It will likely take some trial and error to get it stressed enough.
> > You'll have to start a bunch or processes and look at where they're
> > getting their memory
>
> See, I don't think that user processes using highmem pages is testing
> highmem much. So we have user pages mapped by PTE's - what's changed?
> Not a whole lot. It's when we use bounce buffers in the kernel or ask
> the kernel to map user pages or otherwise trigger the kmap/kunmap code
> that I'm interested in.
I agree. What I had in mind was causing the kernel to kmap pages for some
reason like to copy user data into the buffer cache of a block device (see
generic_file_write). I would make a pgm to allocate some mem (like the size
of your lowmem), mlock it down, then fork some processes that do short writes
to a block device or something like that. I think that would do it.
Did you mentioned that your scsi ctlr or drive was bad? If so, you'll have to
find some other block device, /dev/ram? maybe??
Mark
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-02-07 23:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-05 1:32 Highmem on PPC? Val Henson
2002-02-05 12:52 ` benh
2002-02-05 18:56 ` Val Henson
2002-02-05 19:33 ` Benjamin Herrenschmidt
2002-02-05 19:42 ` Val Henson
2002-02-05 19:47 ` Benjamin Herrenschmidt
2002-02-07 12:27 ` Christopher Murtagh
2002-02-07 21:43 ` Val Henson
2002-02-07 21:51 ` Benjamin Herrenschmidt
2002-02-07 21:56 ` Val Henson
2002-02-07 21:59 ` Benjamin Herrenschmidt
2002-02-07 21:53 ` Mark A. Greer
2002-02-07 21:58 ` Val Henson
2002-02-07 23:09 ` Mark A. Greer [this message]
2002-02-08 3:02 ` Tom Rini
2002-02-08 6:05 ` Christopher Murtagh
2002-02-08 6:25 ` Val Henson
2002-02-08 17:36 ` Val Henson
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=3C63091A.4D9EA2D8@mvista.com \
--to=mgreer@mvista$(echo .)com \
--cc=benh@kernel$(echo .)crashing.org \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
--cc=val@nmt$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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