From: Sizhao Yang <zaoyang@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: ASPLOV miss ratio porting to planet labs kernel
Date: Thu, 7 Jul 2005 12:28:09 -0500 [thread overview]
Message-ID: <f0655b9a0507071028209af86e@mail.gmail.com> (raw)
Hi all,
I was wondering if someone could help me with this. I'm porting an
ASPLOV paper miss ratio curve from 2.4.20 2.6.11.6 and eventually to
Planet Labs kernel. It's a novel idea for memory management. In
porting I at run time I'm consistently hitting kernel bugs at four
different places bad_page, bad_range, in rmap.c
BUG(page_mapcount(page)< 0), and failing at apm_do_idle. All of these
functions except apm_do_idle seem to be new functions from 2.4.20 to
2.6.11.6. I'm pretty sure I'm forgetting to account for certain
things when modifying the pages, but I'm not sure where.
What I'm doing in the port is resetting protection bits so that when
it page faults. It will calculate a miss ratio based on the number of
accessed bits and other information. After I gather the information I
will reset the accessed bits. Then based on previous miss ratios and
current miss ratio it will give out memory to different processes
based on that. That's the general idea. For more specifics:
http://carmen.cs.uiuc.edu/paper/ASPLOS04-Zhou.pdf
I've narrowed it down to primarily when I call the following functions:
ptep_test_and_clear_young,
static inline pte_t pte_mknominor(pte_t pte) { (pte).pte_low &=
~_PAGE_PROTNONE; return pte; }
static inline pte_t pte_mkminor(pte_t pte) { (pte).pte_low |=
_PAGE_PROTNONE; return pte; }
static inline pte_t pte_mkpresent(pte_t pte) { (pte).pte_low |=
_PAGE_PRESENT; return pte; }
static inline pte_t pte_mkabsent(pte_t pte) { (pte).pte_low &=
~_PAGE_PRESENT; return pte; }
When I don't have those functions in my code the kernel doesn't crash,
but when I do they crash. So, my question is am I to page accounting
aspects? I looked at rmap functions for incrementing the _mapcount but
they seem to be only for when a pte is copied. Should I be
incrementing the pagecount at any point? rmap.c
BUG(page_mapcount(page)< 0) is invoked when the accessed bits are
cleared in zap_pte, but I don't know how the page is being corrupted.
So, my main issue is if anyone can help point me to the direction
where a page could be corrupted I would greatly appreciate.
I'd appreciate any general direction anyone can point me at. Thanks
in advance. I look forward to hearing from anyone.
Zao
next reply other threads:[~2005-07-07 17:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-07 17:28 Sizhao Yang [this message]
2005-07-08 4:28 ` ASPLOV miss ratio porting to planet labs kernel Marcelo Tosatti
2005-07-15 18:03 ` Sizhao Yang
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=f0655b9a0507071028209af86e@mail.gmail.com \
--to=zaoyang@gmail.com \
--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