From: "Paul R. Wilson" <wilson@cs.utexas.edu>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: linux-mm@kvack.org, wilson@cs.utexas.edu
Subject: Re: question about try_to_swap_out()
Date: Tue, 12 Jan 1999 12:42:52 -0600 [thread overview]
Message-ID: <199901121842.MAA28563@feta.cs.utexas.edu> (raw)
>From sct@redhat.com Tue Jan 12 12:15:03 1999
>Subject: Re: question about try_to_swap_out()
>
>Hi,
>
>On Tue, 12 Jan 1999 10:58:52 -0600, "Paul R. Wilson"
><wilson@cs.utexas.edu> said:
>
>> I would think that it could be significant if you're skipping DMA
>> pages, which are valuable. You want to get them back in a timely
>> manner, so you want to go ahead and age them normally.
>
>We don't ever do that. We can _require_ a DMA allocation, but we never
>explicitly avoid allocating DMA pages.
Sorry, I said it backwards. I meant "non-DMA", not "DMA".
What I mean is that if try_to_swap_out() is told to look for a DMA page
(via the __GFP_DMA flag in the gfp_maks argument), it skips non-DMA
pages in terms of re-setting their reference bits---the clock sweeps
right by them without re-setting their reference bits.
It seems to me that this means that if the clock reaches a non-DMA'able
page whose reference bit is set, that bit will stay set for at least
another clock sweep IF try_to_swap_out() is looking for a DMA page.
I don't know whether it would ever occur in practice, but it seems
that a non-DMA page could stay in memory indefinitely after the
last touch to it, if it just happens that the clock hand keeps
sweeping by that page at times that it's looking for DMA pages.
The page would keep getting skipped.
It seems to me that the test about DMA's ought to be broken
out of the conditional that tests whether the page is locked
or reserved, and moved after the testing and re-setting of
the reference bit. (Maybe the test for locked pages, too. I'm
not sure about what's going on with locking.) This would make
the code more comprehensible, if nothing else.
---
More generally, it seems to me that the stuff about DMAable
pages is inelegant. Would it work to just keep sweeping the
clock until the right kind of memory is freed, rather than
putting weird tests inside the clock-sweeping code itself,
and passing weird flags down through the call chains?
(Is the time cost of freeing pages of the "wrong" type signficant?
I wouldn't think so---amortized, it's no more expensive because
it's work we should do anyway. And if you're thrashing, CPU
cost isn't the big issue.)
I assume there's a reason it's done this way---e.g., that
finding the wrong kind of free able page (and _doing_ something
with it) temporarily uses more memory or something. I'd
think that could be gotten around. It seems to me that there
has to be a simpler way to do things, but I could be missing
the boat.
Whatever the rationale, I'd like to document it.
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
next reply other threads:[~1999-01-12 18:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-12 18:42 Paul R. Wilson [this message]
-- strict thread matches above, loose matches on Subject: below --
1999-01-12 16:58 question about try_to_swap_out() Paul R. Wilson
1999-01-12 18:14 ` Stephen C. Tweedie
1999-01-14 10:15 ` ralf
1999-01-11 3:38 Paul R. Wilson
1999-01-12 16:10 ` Stephen C. Tweedie
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=199901121842.MAA28563@feta.cs.utexas.edu \
--to=wilson@cs.utexas.edu \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).