Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > I want to know when a page is going to be modified so that I
> > can predict the state of the cache as much as possible. I don't want
> > userspace processes corrupting the cache in unrecorded ways.
>
> There are two cases:
>
> 1) Metadata. If
Daniel Phillips [EMAIL PROTECTED] wrote:
I want to know when a page is going to be modified so that I
can predict the state of the cache as much as possible. I don't want
userspace processes corrupting the cache in unrecorded ways.
There are two cases:
1) Metadata. If anybody is
On Monday 15 August 2005 23:15, David Howells wrote:
> I want to know when a page is going to be modified so that I
> can predict the state of the cache as much as possible. I don't want
> userspace processes corrupting the cache in unrecorded ways.
There are two cases:
1) Metadata. If
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > Now we already do this at one level: RAM. The page cache _is_ such a cache,
> > but whilst it's much faster than a disk, it is severely restricted in size
>
> Did you just suggest that 16 TB/address_space is too small to cache NFS pages?
No. I
Daniel Phillips [EMAIL PROTECTED] wrote:
Now we already do this at one level: RAM. The page cache _is_ such a cache,
but whilst it's much faster than a disk, it is severely restricted in size
Did you just suggest that 16 TB/address_space is too small to cache NFS pages?
No. I meant that
On Monday 15 August 2005 23:15, David Howells wrote:
I want to know when a page is going to be modified so that I
can predict the state of the cache as much as possible. I don't want
userspace processes corrupting the cache in unrecorded ways.
There are two cases:
1) Metadata. If anybody
On Saturday, 13 of August 2005 01:04, Daniel Phillips wrote:
> On Saturday 13 August 2005 08:20, Rafael J. Wysocki wrote:
> > On Friday, 12 of August 2005 21:56, Daniel Phillips wrote:
> > > I still don't see why you can't lift your flags up into the VMA. The
> > > rmap mechanism is there
On Saturday, 13 of August 2005 01:04, Daniel Phillips wrote:
On Saturday 13 August 2005 08:20, Rafael J. Wysocki wrote:
On Friday, 12 of August 2005 21:56, Daniel Phillips wrote:
I still don't see why you can't lift your flags up into the VMA. The
rmap mechanism is there precisely to let
On Saturday 13 August 2005 08:20, Rafael J. Wysocki wrote:
> On Friday, 12 of August 2005 21:56, Daniel Phillips wrote:
> > I still don't see why you can't lift your flags up into the VMA. The
> > rmap mechanism is there precisely to let you get from the physical page
> > to the users and user
On Friday, 12 of August 2005 21:56, Daniel Phillips wrote:
> On Thursday 11 August 2005 20:36, Rafael J. Wysocki wrote:
> > > >> > Swsusp is the main "is valid ram" user I have in mind here. It
> > > >> > wants to know whether or not it should save and restore the
> > > >> > memory of a given
On Thursday 11 August 2005 20:36, Rafael J. Wysocki wrote:
> > >> > Swsusp is the main "is valid ram" user I have in mind here. It
> > >> > wants to know whether or not it should save and restore the
> > >> > memory of a given `struct page`.
> > >>
> > >> Why can't it follow the rmap chain?
> > >
On Thursday 11 August 2005 20:49, David Howells wrote:
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > To be honest I'm having some trouble following this through logically.
> > I'll read through a few more times and see if that fixes the problem.
> > This seems cluster-related, so I have an
On Thursday 11 August 2005 20:49, David Howells wrote:
Daniel Phillips [EMAIL PROTECTED] wrote:
To be honest I'm having some trouble following this through logically.
I'll read through a few more times and see if that fixes the problem.
This seems cluster-related, so I have an interest.
On Thursday 11 August 2005 20:36, Rafael J. Wysocki wrote:
Swsusp is the main is valid ram user I have in mind here. It
wants to know whether or not it should save and restore the
memory of a given `struct page`.
Why can't it follow the rmap chain?
It is walking physical
On Friday, 12 of August 2005 21:56, Daniel Phillips wrote:
On Thursday 11 August 2005 20:36, Rafael J. Wysocki wrote:
Swsusp is the main is valid ram user I have in mind here. It
wants to know whether or not it should save and restore the
memory of a given `struct page`.
On Saturday 13 August 2005 08:20, Rafael J. Wysocki wrote:
On Friday, 12 of August 2005 21:56, Daniel Phillips wrote:
I still don't see why you can't lift your flags up into the VMA. The
rmap mechanism is there precisely to let you get from the physical page
to the users and user data,
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> To be honest I'm having some trouble following this through logically. I'll
> read through a few more times and see if that fixes the problem. This seems
> cluster-related, so I have an interest.
Well, perhaps I can explain the function for which
Hi,
On Wednesday, 10 of August 2005 23:56, Martin J. Bligh wrote:
> --On Wednesday, August 10, 2005 23:50:22 +0200 Pavel Machek <[EMAIL
> PROTECTED]> wrote:
>
> > Hi!
> >
> >> > Swsusp is the main "is valid ram" user I have in mind here. It
> >> > wants to know whether or not it should save
Hi,
On Wednesday, 10 of August 2005 23:50, Pavel Machek wrote:
> Hi!
>
> > > Swsusp is the main "is valid ram" user I have in mind here. It
> > > wants to know whether or not it should save and restore the
> > > memory of a given `struct page`.
> >
> > Why can't it follow the rmap chain?
>
>
Benjamin Herrenschmidt wrote:
On Tue, 2005-08-09 at 20:41 +0100, Russell King wrote:
On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
have a backing struct page for that address. Could be an IO mapped
Benjamin Herrenschmidt wrote:
On Tue, 2005-08-09 at 20:41 +0100, Russell King wrote:
On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
have a backing struct page for that address. Could be an IO mapped
Hi,
On Wednesday, 10 of August 2005 23:50, Pavel Machek wrote:
Hi!
Swsusp is the main is valid ram user I have in mind here. It
wants to know whether or not it should save and restore the
memory of a given `struct page`.
Why can't it follow the rmap chain?
It is walking
Hi,
On Wednesday, 10 of August 2005 23:56, Martin J. Bligh wrote:
--On Wednesday, August 10, 2005 23:50:22 +0200 Pavel Machek [EMAIL
PROTECTED] wrote:
Hi!
Swsusp is the main is valid ram user I have in mind here. It
wants to know whether or not it should save and restore the
Daniel Phillips [EMAIL PROTECTED] wrote:
To be honest I'm having some trouble following this through logically. I'll
read through a few more times and see if that fixes the problem. This seems
cluster-related, so I have an interest.
Well, perhaps I can explain the function for which I'm
On Thursday 11 August 2005 00:27, David Howells wrote:
> What happens is this:
>
> (1) readpage() is issued against NFS (for example).
>
> (2) NFS consults the local cache, and finds the page isn't available
> there.
>
> (3) NFS reads the page from the server.
>
> (4) NFS sets PG_fs_misc and
--On Wednesday, August 10, 2005 23:50:22 +0200 Pavel Machek <[EMAIL PROTECTED]>
wrote:
> Hi!
>
>> > Swsusp is the main "is valid ram" user I have in mind here. It
>> > wants to know whether or not it should save and restore the
>> > memory of a given `struct page`.
>>
>> Why can't it follow
Hi!
> > Swsusp is the main "is valid ram" user I have in mind here. It
> > wants to know whether or not it should save and restore the
> > memory of a given `struct page`.
>
> Why can't it follow the rmap chain?
It is walking physical memory, not memory managment chains. I need
something like:
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > An extra page flag beyond PG_uptodate, PG_lock and PG_writeback is
> > required to make readpage through the cache non-synchronous.
Sorry, I meant to say "filesystem cache": FS-Cache/CacheFS.
> Interesting, have you got a pointer to a full
On Wednesday 10 August 2005 23:13, David Howells wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > ...kill PG_checked please :) Or at least keep it from spreading.
> >
> > It already spread - ext3 is using it and I think reiser4. I thought I
> > had a patch to rename it to PG_misc1 or
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > ...kill PG_checked please :) Or at least keep it from spreading.
> >
>
> It already spread - ext3 is using it and I think reiser4. I thought I had
> a patch to rename it to PG_misc1 or somesuch, but no. It's mandate becomes
> "filesystem-specific
On Tue, 2005-08-09 at 20:41 +0100, Russell King wrote:
> On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
> > pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
> > have a backing struct page for that address. Could be an IO mapped device,
> > a small memory
On Tue, 2005-08-09 at 20:41 +0100, Russell King wrote:
On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
have a backing struct page for that address. Could be an IO mapped device,
a small memory hole,
Andrew Morton [EMAIL PROTECTED] wrote:
...kill PG_checked please :) Or at least keep it from spreading.
It already spread - ext3 is using it and I think reiser4. I thought I had
a patch to rename it to PG_misc1 or somesuch, but no. It's mandate becomes
filesystem-specific page flag.
On Wednesday 10 August 2005 23:13, David Howells wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
...kill PG_checked please :) Or at least keep it from spreading.
It already spread - ext3 is using it and I think reiser4. I thought I
had a patch to rename it to PG_misc1 or somesuch, but
Daniel Phillips [EMAIL PROTECTED] wrote:
An extra page flag beyond PG_uptodate, PG_lock and PG_writeback is
required to make readpage through the cache non-synchronous.
Sorry, I meant to say filesystem cache: FS-Cache/CacheFS.
Interesting, have you got a pointer to a full explanation? Is
Hi!
Swsusp is the main is valid ram user I have in mind here. It
wants to know whether or not it should save and restore the
memory of a given `struct page`.
Why can't it follow the rmap chain?
It is walking physical memory, not memory managment chains. I need
something like:
static
--On Wednesday, August 10, 2005 23:50:22 +0200 Pavel Machek [EMAIL PROTECTED]
wrote:
Hi!
Swsusp is the main is valid ram user I have in mind here. It
wants to know whether or not it should save and restore the
memory of a given `struct page`.
Why can't it follow the rmap chain?
It
On Thursday 11 August 2005 00:27, David Howells wrote:
What happens is this:
(1) readpage() is issued against NFS (for example).
(2) NFS consults the local cache, and finds the page isn't available
there.
(3) NFS reads the page from the server.
(4) NFS sets PG_fs_misc and tells the
Hi Nick,
Did you know that your patches do not actually specify which kernel tree you
diffed against?
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
>> On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
>>> pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
>>> have a backing struct page for that address. Could be an IO mapped device,
>>> a small memory hole, whatever.
>>
>> The only things which have a
On Wednesday 10 August 2005 01:36, Hugh Dickins wrote:
> On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
> > - We already have a refcount
> > - We have a field where putting a flag isn't that much of a problem
> > - It can be difficult to get page refcounting right when dealing with
> >
--On Tuesday, August 09, 2005 20:41:00 +0100 Russell King <[EMAIL PROTECTED]>
wrote:
> On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
>> pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
>> have a backing struct page for that address. Could be an IO
On Tue, 9 Aug 2005, Russell King wrote:
> On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
> > pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
> > have a backing struct page for that address. Could be an IO mapped device,
> > a small memory hole,
On Wednesday 10 August 2005 06:17, Hugh Dickins wrote:
> There might be a case for packaging repeated arguments into structures
> (though several of these levels are inlined anyway), but that's some
> other exercise entirely, shouldn't get in the way of removing Reserved.
Agreed, an entirely
On Wed, 10 Aug 2005, Daniel Phillips wrote:
> On Tuesday 09 August 2005 10:15, Nick Piggin wrote:
> > Daniel Phillips wrote:
> > > Why don't you pass the vma in zap_details?
> >
> > Possibly. I initially did it that way, but it ended up fattening
> > paths that don't use details.
>
> It should
Hi,
On Tue, 9 Aug 2005, Hugh Dickins wrote:
> PageReserved is about those pages which are managed by PageReserved.
> But quite what it means is unclear, one of the reasons to eliminate it.
> (Why is kernel text PageReserved?)
Short answer: /dev/mem
(Amazing that nobody mentioned it so far...)
On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
> pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
> have a backing struct page for that address. Could be an IO mapped device,
> a small memory hole, whatever.
The only things which have a struct page is RAM.
On Tue, Aug 09, 2005 at 07:29:30PM +1000, Nick Piggin wrote:
> Russell King wrote:
> > The usage of "valid ram" here is confusing - that's not what PageReserved
> > is all about. It's about valid RAM which is managed by method other
> > than the usual page counting. Non-reserved RAM is also
On Tuesday 09 August 2005 19:49, Nick Piggin wrote:
> Swsusp is the main "is valid ram" user I have in mind here. It
> wants to know whether or not it should save and restore the
> memory of a given `struct page`.
Why can't it follow the rmap chain?
Regards,
Daniel
-
To unsubscribe from this
On Tuesday 09 August 2005 19:49, Nick Piggin wrote:
> Benjamin Herrenschmidt wrote:
> > I have no problem keeping PG_reserved for that, and _ONLY_ for that.
> > (though i'd rather see it renamed then). I'm just afraid by doing so,
> > some drivers will jump in the gap and abuse it again...
>
>
On Tuesday 09 August 2005 10:15, Nick Piggin wrote:
> Daniel Phillips wrote:
> > Why don't you pass the vma in zap_details? For that matter, why are addr
> > and end still passed down the zap chain when zap_details appears to
> > duplicate that information? OK, it is because zap_details is NULL
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
> On Tue, 2005-08-09 at 15:50 +0100, Hugh Dickins wrote:
> > On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
> > >
> > > Well, a refcounting bug would let them be freed and kaboom ... That's
> > > why a "PG_not_your_ram_dammit" bit would be
On Tue, 2005-08-09 at 15:50 +0100, Hugh Dickins wrote:
> On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
> >
> > > But you don't mind if they are refcounted, do you?
> > > Just so long as they start out from 1 so never get freed.
> >
> > Well, a refcounting bug would let them be freed and
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
>
> > But you don't mind if they are refcounted, do you?
> > Just so long as they start out from 1 so never get freed.
>
> Well, a refcounting bug would let them be freed and kaboom ... That's
> why a "PG_not_your_ram_dammit" bit would be useful.
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
>
> > ioremap is making a similar check to the one remap_pfn_range used
> > to make; but I see no good reason for it at all. ioremap should be
> > allowed to map whatever the caller asked, just as memset is allowed
> > to set whatever the caller
> We do what's most efficient for the core. Which I think is refcount
> both ways regardless, since these "page"s are exceptional, and the
> majority really do need refcounting.
Well, refcounting _might_ be useful for some usage of these, but we
simply must make sure that those pages are never
--Russell King <[EMAIL PROTECTED]> wrote (on Tuesday, August 09, 2005 08:08:53
+0100):
> On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
>> That would work for swsusp, but there are other users that want to
>> know if a struct page is valid ram (eg. ioremap), so in that case
>>
> Who can tell? rmk's mail sugggests it should work on some valid RAM.
Not really. If I understand Russell here, that RAM has been "put aside"
for use by fancy stuff and is de-facto out of control of the normal page
allocator and refcounting. In this case, I see no reason why it couldn't
be
On Tue, 2005-08-09 at 23:15 +1000, Nick Piggin wrote:
> I understand what you mean, and I agree. Though as far away from the
> business end of the drivers I am, I tend to get the feeling that
> drivers need the most hand holding.
they do. It's important to make driver APIs as fool proof as
Hugh Dickins wrote:
On Tue, 9 Aug 2005, Nick Piggin wrote:
But in either case: I agree that it is probably not a great loss
to remove the check, although considering it will be needed for
swsusp anyway...
swsusp (and I think crashdump has a similar need) is a very different
case: it's
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
> >
> > What we don't have is something to indicate the page does not point
> > to valid ram.
>
> I have no problem keeping PG_reserved for that, and _ONLY_ for that.
Yes, if a table won't suffice.
> (though i'd rather see it renamed then).
On Tue, 9 Aug 2005, Nick Piggin wrote:
> Hugh Dickins wrote:
> > I think Nick is treating the "use" of PageReserved in ioremap much too
> > reverentially. Fine to leave its removal from there to a later stage,
> > but why shouldn't that also be removed?
>
> Well, as far as I had been able to
Hugh Dickins wrote:
You're right (though I imagine might sometimes be holes rather than RAM).
Yep. These holes are what I have in mind, and random other things
like the !(bad_ppro && page_kills_ppro(pfn)) check.
[...]
I think Nick is treating the "use" of PageReserved in ioremap much too
On Tuesday, 9 of August 2005 11:31, Nick Piggin wrote:
> Arjan van de Ven wrote:
> > On Tue, 2005-08-09 at 08:08 +0100, Russell King wrote:
>
> >>Can we straighten out the terminology so it's less confusing please?
> >>
> >
> >
> > and. can we make a general page_is_ram() function that does
Arjan van de Ven wrote:
On Tue, 2005-08-09 at 19:31 +1000, Nick Piggin wrote:
Arjan van de Ven wrote:
and. can we make a general page_is_ram() function that does what it
says? on x86 it can go via the e820 table, other architectures can do
whatever they need
That would be very
Benjamin Herrenschmidt wrote:
I have no problem keeping PG_reserved for that, and _ONLY_ for that.
(though i'd rather see it renamed then). I'm just afraid by doing so,
some drivers will jump in the gap and abuse it again...
Sure it would be renamed (better yet may be a slower
On Tue, 2005-08-09 at 19:31 +1000, Nick Piggin wrote:
> Arjan van de Ven wrote:
> > On Tue, 2005-08-09 at 08:08 +0100, Russell King wrote:
>
> >>Can we straighten out the terminology so it's less confusing please?
> >>
> >
> >
> > and. can we make a general page_is_ram() function that does
Arjan van de Ven wrote:
On Tue, 2005-08-09 at 08:08 +0100, Russell King wrote:
Can we straighten out the terminology so it's less confusing please?
and. can we make a general page_is_ram() function that does what it
says? on x86 it can go via the e820 table, other architectures can do
Russell King wrote:
On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
That would work for swsusp, but there are other users that want to
know if a struct page is valid ram (eg. ioremap), so in that case
swsusp would not be able to mess with the flag.
The usage of "valid ram" here
On Tue, 9 Aug 2005, Russell King wrote:
> On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
> > That would work for swsusp, but there are other users that want to
> > know if a struct page is valid ram (eg. ioremap), so in that case
> > swsusp would not be able to mess with the flag.
>
> Can we straighten out the terminology so it's less confusing please?
Well, RAM that isn't managed by standard page counting could be
considered a some sort of weird MMIO :)
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
> Basically, it was doing a whole lot of vaguely related things. It
> was set for ZERO_PAGE pages. It was (and still is) set for struct
> pages that don't point to valid ram. Drivers set it, hoping it will
> do something magical for them.
>
> And yes, the VM_RESERVED flag is able to replace
On Tue, 2005-08-09 at 08:08 +0100, Russell King wrote:
> On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
> > That would work for swsusp, but there are other users that want to
> > know if a struct page is valid ram (eg. ioremap), so in that case
> > swsusp would not be able to mess
On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
> That would work for swsusp, but there are other users that want to
> know if a struct page is valid ram (eg. ioremap), so in that case
> swsusp would not be able to mess with the flag.
The usage of "valid ram" here is confusing -
On Tuesday 09 August 2005 19:49, Nick Piggin wrote:
Benjamin Herrenschmidt wrote:
I have no problem keeping PG_reserved for that, and _ONLY_ for that.
(though i'd rather see it renamed then). I'm just afraid by doing so,
some drivers will jump in the gap and abuse it again...
Sure it
On Tuesday 09 August 2005 19:49, Nick Piggin wrote:
Swsusp is the main is valid ram user I have in mind here. It
wants to know whether or not it should save and restore the
memory of a given `struct page`.
Why can't it follow the rmap chain?
Regards,
Daniel
-
To unsubscribe from this list:
On Tue, Aug 09, 2005 at 07:29:30PM +1000, Nick Piggin wrote:
Russell King wrote:
The usage of valid ram here is confusing - that's not what PageReserved
is all about. It's about valid RAM which is managed by method other
than the usual page counting. Non-reserved RAM is also valid RAM,
On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
have a backing struct page for that address. Could be an IO mapped device,
a small memory hole, whatever.
The only things which have a struct page is RAM.
Hi,
On Tue, 9 Aug 2005, Hugh Dickins wrote:
PageReserved is about those pages which are managed by PageReserved.
But quite what it means is unclear, one of the reasons to eliminate it.
(Why is kernel text PageReserved?)
Short answer: /dev/mem
(Amazing that nobody mentioned it so far...)
To
On Wed, 10 Aug 2005, Daniel Phillips wrote:
On Tuesday 09 August 2005 10:15, Nick Piggin wrote:
Daniel Phillips wrote:
Why don't you pass the vma in zap_details?
Possibly. I initially did it that way, but it ended up fattening
paths that don't use details.
It should not, it only
On Tue, 9 Aug 2005, Russell King wrote:
On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
have a backing struct page for that address. Could be an IO mapped device,
a small memory hole, whatever.
On Wednesday 10 August 2005 06:17, Hugh Dickins wrote:
There might be a case for packaging repeated arguments into structures
(though several of these levels are inlined anyway), but that's some
other exercise entirely, shouldn't get in the way of removing Reserved.
Agreed, an entirely
--On Tuesday, August 09, 2005 20:41:00 +0100 Russell King [EMAIL PROTECTED]
wrote:
On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
have a backing struct page for that address. Could be an IO mapped
On Wednesday 10 August 2005 01:36, Hugh Dickins wrote:
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
- We already have a refcount
- We have a field where putting a flag isn't that much of a problem
- It can be difficult to get page refcounting right when dealing with
such
On Tue, Aug 09, 2005 at 07:38:52AM -0700, Martin J. Bligh wrote:
pfn_valid() doesn't tell you it's RAM or not - it tells you whether you
have a backing struct page for that address. Could be an IO mapped device,
a small memory hole, whatever.
The only things which have a struct page is RAM.
Hi Nick,
Did you know that your patches do not actually specify which kernel tree you
diffed against?
Regards,
Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
That would work for swsusp, but there are other users that want to
know if a struct page is valid ram (eg. ioremap), so in that case
swsusp would not be able to mess with the flag.
The usage of valid ram here is confusing - that's
On Tue, 2005-08-09 at 08:08 +0100, Russell King wrote:
On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
That would work for swsusp, but there are other users that want to
know if a struct page is valid ram (eg. ioremap), so in that case
swsusp would not be able to mess with the
Basically, it was doing a whole lot of vaguely related things. It
was set for ZERO_PAGE pages. It was (and still is) set for struct
pages that don't point to valid ram. Drivers set it, hoping it will
do something magical for them.
And yes, the VM_RESERVED flag is able to replace most
Can we straighten out the terminology so it's less confusing please?
Well, RAM that isn't managed by standard page counting could be
considered a some sort of weird MMIO :)
Ben.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Tue, 9 Aug 2005, Russell King wrote:
On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
That would work for swsusp, but there are other users that want to
know if a struct page is valid ram (eg. ioremap), so in that case
swsusp would not be able to mess with the flag.
The
Russell King wrote:
On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
That would work for swsusp, but there are other users that want to
know if a struct page is valid ram (eg. ioremap), so in that case
swsusp would not be able to mess with the flag.
The usage of valid ram here
Arjan van de Ven wrote:
On Tue, 2005-08-09 at 08:08 +0100, Russell King wrote:
Can we straighten out the terminology so it's less confusing please?
and. can we make a general page_is_ram() function that does what it
says? on x86 it can go via the e820 table, other architectures can do
Benjamin Herrenschmidt wrote:
I have no problem keeping PG_reserved for that, and _ONLY_ for that.
(though i'd rather see it renamed then). I'm just afraid by doing so,
some drivers will jump in the gap and abuse it again...
Sure it would be renamed (better yet may be a slower
On Tue, 2005-08-09 at 19:31 +1000, Nick Piggin wrote:
Arjan van de Ven wrote:
On Tue, 2005-08-09 at 08:08 +0100, Russell King wrote:
Can we straighten out the terminology so it's less confusing please?
and. can we make a general page_is_ram() function that does what it
says?
Arjan van de Ven wrote:
On Tue, 2005-08-09 at 19:31 +1000, Nick Piggin wrote:
Arjan van de Ven wrote:
and. can we make a general page_is_ram() function that does what it
says? on x86 it can go via the e820 table, other architectures can do
whatever they need
That would be very
On Tuesday, 9 of August 2005 11:31, Nick Piggin wrote:
Arjan van de Ven wrote:
On Tue, 2005-08-09 at 08:08 +0100, Russell King wrote:
Can we straighten out the terminology so it's less confusing please?
and. can we make a general page_is_ram() function that does what it
says?
Hugh Dickins wrote:
You're right (though I imagine might sometimes be holes rather than RAM).
Yep. These holes are what I have in mind, and random other things
like the !(bad_ppro page_kills_ppro(pfn)) check.
[...]
I think Nick is treating the use of PageReserved in ioremap much too
On Tue, 9 Aug 2005, Nick Piggin wrote:
Hugh Dickins wrote:
I think Nick is treating the use of PageReserved in ioremap much too
reverentially. Fine to leave its removal from there to a later stage,
but why shouldn't that also be removed?
Well, as far as I had been able to gather,
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
What we don't have is something to indicate the page does not point
to valid ram.
I have no problem keeping PG_reserved for that, and _ONLY_ for that.
Yes, if a table won't suffice.
(though i'd rather see it renamed then).
Definitely.
1 - 100 of 130 matches
Mail list logo
