* question about try_to_swap_out()
@ 1999-01-11 3:38 Paul R. Wilson
1999-01-12 16:10 ` Stephen C. Tweedie
0 siblings, 1 reply; 6+ messages in thread
From: Paul R. Wilson @ 1999-01-11 3:38 UTC (permalink / raw
To: linux-mm
After checking that that a page is present and pageable, try_to_swap_out()
checks to see if the page is reserved or locked or not DMA'able when
where looking for a DMA page. If any of these three things is
true, it returns 0 without changing anything.
It seems to me that it should go ahead and check the pte age bit,
and update the page frame's PG_referenced bit, before returning 0.
One case I'm concerned about is a non-DMA page whose reference bit
doesn't get reset as usual. This page will still look recently-touched
at the next clock sweep, and that will make it stay cached longer,
just because we were looking for a DMA'able page when the clock
hand reached it this time.
I'm unclear what the significance is for a locked page.
Am I off-base here, or should the conditional that checks to see
whether a page is young (and updates the reference bits) be moved
up ahead of the conditional that checks to see whether a page
is (reserved | locked | not-dma-but-we-need-dma)?
Apologies if I'm way off base here.
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: question about try_to_swap_out()
1999-01-11 3:38 question about try_to_swap_out() Paul R. Wilson
@ 1999-01-12 16:10 ` Stephen C. Tweedie
0 siblings, 0 replies; 6+ messages in thread
From: Stephen C. Tweedie @ 1999-01-12 16:10 UTC (permalink / raw
To: Paul R. Wilson; +Cc: linux-mm, Stephen Tweedie
Hi,
On Sun, 10 Jan 1999 21:38:46 -0600, "Paul R. Wilson"
<wilson@cs.utexas.edu> said:
> After checking that that a page is present and pageable, try_to_swap_out()
> checks to see if the page is reserved or locked or not DMA'able when
> where looking for a DMA page. If any of these three things is
> true, it returns 0 without changing anything.
> It seems to me that it should go ahead and check the pte age bit,
> and update the page frame's PG_referenced bit, before returning 0.
Not really. Reserved pages never get swapped anyway. For DMA, we don't
want to disturb non-DMA processes at all --- the demand for DMA and
non-DMA pages might be very different. For locked pages, we expect this
to be sufficiently rare that it's totally irrelevant whether we age the
page or not.
> Am I off-base here, or should the conditional that checks to see
> whether a page is young (and updates the reference bits) be moved
> up ahead of the conditional that checks to see whether a page
> is (reserved | locked | not-dma-but-we-need-dma)?
I really don't think it's that important!
--Stephen
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: question about try_to_swap_out()
@ 1999-01-12 16:58 Paul R. Wilson
1999-01-12 18:14 ` Stephen C. Tweedie
0 siblings, 1 reply; 6+ messages in thread
From: Paul R. Wilson @ 1999-01-12 16:58 UTC (permalink / raw
To: Stephen C. Tweedie; +Cc: linux-mm
>From sct@redhat.com Tue Jan 12 10:10:50 1999
>From: "Stephen C. Tweedie" <sct@redhat.com>
>Cc: linux-mm@kvack.org, Stephen Tweedie <sct@redhat.com>
>Subject: Re: question about try_to_swap_out()
>
>Hi,
>
>On Sun, 10 Jan 1999 21:38:46 -0600, "Paul R. Wilson"
><wilson@cs.utexas.edu> said:
>
>> After checking that that a page is present and pageable, try_to_swap_out()
>> checks to see if the page is reserved or locked or not DMA'able when
>> where looking for a DMA page. If any of these three things is
>> true, it returns 0 without changing anything.
>
>> It seems to me that it should go ahead and check the pte age bit,
>> and update the page frame's PG_referenced bit, before returning 0.
>
>Not really. Reserved pages never get swapped anyway.
Right. Not only that, they're very seldom touched, so the pte bit
will generally not be set, and the branch won't be taken. [ As I
understand it, reserved pages are not generally used at all---or
am I really mistaken, and they're reserved for important purposes
rather than being a pool of pages that's only used in an extreme
pinch? ]
> For DMA, we don't
>want to disturb non-DMA processes at all --- the demand for DMA and
>non-DMA pages might be very different.
I guess I don't understand what's going on with DMA pages. (And I need
to, for Part II of the Linux VM doc I'm writing.)
I've been under the impression that the DMA flag in the page struct
was describing the page frame, and whether it's DMAable (not describing
whether there was a DMA going on). As I [mis?] understood it, this
is used on platforms where some memory is DMA'able and some isn't,
but a page used for VM might or might not be DMA'able. (Is that
wrong? I've been wondering. I'd think you'd DMA into and out
of page frames for paging.)
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.
>For locked pages, we expect this
>to be sufficiently rare that it's totally irrelevant whether we age the
>page or not.
Right. So I figured it wouldn't hurt to do it the conceptually
"Right" way. I figured that if a locked page was not being touched
by teh program, it should be aging normally---the aging stuff is
about recording what the program is doing with the pages, not about
what the VM system chooses to do behind the program's back.
>> Am I off-base here, or should the conditional that checks to see
>> whether a page is young (and updates the reference bits) be moved
>> up ahead of the conditional that checks to see whether a page
>> is (reserved | locked | not-dma-but-we-need-dma)?
>
>I really don't think it's that important!
I didn't think it was important, but couldn't be sure. There's
lots of weirdness in the VM code, such that it's hard to tell
what is weird for a really good reason, and what's weird for
no particular reason, and what's weird because it matters a little
bit, but not much. It's fairly confusing for a newbie---you just
can't tell what's what, half the time.
In general, it would be nice if the code just made sense when
you read it, and this is one of those cases where you just go
"huh?" and start doubting that you have any idea what the issues
are.
At any rate, thanks for the clarification, and thanks in advance
for any further clarifications.
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: question about try_to_swap_out()
1999-01-12 16:58 Paul R. Wilson
@ 1999-01-12 18:14 ` Stephen C. Tweedie
1999-01-14 10:15 ` ralf
0 siblings, 1 reply; 6+ messages in thread
From: Stephen C. Tweedie @ 1999-01-12 18:14 UTC (permalink / raw
To: Paul R. Wilson; +Cc: Stephen C. Tweedie, linux-mm
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.
--Stephen
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: question about try_to_swap_out()
@ 1999-01-12 18:42 Paul R. Wilson
0 siblings, 0 replies; 6+ messages in thread
From: Paul R. Wilson @ 1999-01-12 18:42 UTC (permalink / raw
To: Stephen C. Tweedie; +Cc: linux-mm, wilson
>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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: question about try_to_swap_out()
1999-01-12 18:14 ` Stephen C. Tweedie
@ 1999-01-14 10:15 ` ralf
0 siblings, 0 replies; 6+ messages in thread
From: ralf @ 1999-01-14 10:15 UTC (permalink / raw
To: Stephen C. Tweedie, Paul R. Wilson; +Cc: linux-mm
On Tue, Jan 12, 1999 at 06:14:49PM +0000, Stephen C. Tweedie wrote:
> 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.
Which is a problem for certain machines which have distinct pools of DMA-able
memory and memory for normal use by the processor.
Ralf
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-01-14 14:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1999-01-11 3:38 question about try_to_swap_out() Paul R. Wilson
1999-01-12 16:10 ` Stephen C. Tweedie
-- strict thread matches above, loose matches on Subject: below --
1999-01-12 16:58 Paul R. Wilson
1999-01-12 18:14 ` Stephen C. Tweedie
1999-01-14 10:15 ` ralf
1999-01-12 18:42 Paul R. Wilson
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.