Hi. On Wednesday 26 April 2006 08:21, Rafael J. Wysocki wrote: > On Tuesday 25 April 2006 23:18, Nigel Cunningham wrote: > > On Wednesday 26 April 2006 07:12, Rafael J. Wysocki wrote: > > > On Tuesday 25 April 2006 22:32, Pavel Machek wrote: > > > > > > > -unsigned int count_data_pages(void) > > > > > > > > > > > > > > +/** > > > > > > > + * need_to_copy - determine if a page needs to be copied > > > > > > > before saving. + * Returns false if the page can be saved > > > > > > > without copying. + */ > > > > > > > + > > > > > > > +static int need_to_copy(struct page *page) > > > > > > > +{ > > > > > > > + if (!PageLRU(page) || PageCompound(page)) > > > > > > > + return 1; > > > > > > > + if (page_mapped(page)) > > > > > > > + return page_mapped_by_current(page); > > > > > > > + > > > > > > > + return 1; > > > > > > > +} > > > > > > > > > > > > I'd much rather VM internal type stuff get moved *out* of > > > > > > kernel/power :( > > > > > > > > > > Well, I kind of agree, but I don't know where to place it under > > > > > mm/. > > > > > > > > > > > It needs more comments too. Also, how important is it for the > > > > > > page to be off the LRU? > > > > > > > > > > Hm, I'm not sure if that's what you're asking about, but the pages > > > > > off the LRU are handled in a usual way, ie. copied when > > > > > snapshotting the system. The pages _on_ the LRU may be included in > > > > > the snapshot image without copying, but I require them additionally > > > > > to be (a) mapped by someone and (b) not mapped by the current task. > > > > > > > > Why do you _want_ them mapped by someone? > > > > > > Because this means they belong to a task that is frozen and won't touch > > > them (of course unless it's us). The kernel has no reason to access > > > them either (even after we resume devices) except for reclaiming, but > > > that's handled explicitly. Thus it's safe to include them in the image > > > without copying. > > > > > > As I said before, I think the page cache pages may be treated this way > > > too. It probably applies to all of the LRU pages, but there may be some > > > corner cases. The mapped pages are just easy to single out. > > > > It does apply to all of the LRU pages. This is what I've been doing for > > years now. The only corner case I've come across is XFS. It still wants > > to write data even when there's nothing to do and it's threads are frozen > > (IIRC - haven't looked at it for a while). I got around that by freezing > > bdevs when freezing processes. > > This means if we freeze bdevs, we'll be able to save all of the LRU pages, > except for the pages mapped by the current task, without copying. I think > we can try to do this, but we'll need a patch to freeze bdevs for this > purpose. ;-) Isn't that a coincidence? I just happen to have the code right here! Not in a patch form that you'd want though - do you have any refrigerator changes in mm at the moment, or can I use vanilla 2.6.17-rc2 process.c? Regards, Nigel -- See our web page for Howtos, FAQs, the Wiki and mailing list info. http://www.suspend2.net IRC: #suspend2 on Freenode
Attachment:
pgpwUe3oglKS1.pgp
Description: PGP signature
- Follow-Ups:
- Re: [RFC][PATCH] swsusp: support creating bigger images
- From: "Rafael J. Wysocki" <[email protected]>
- Re: [RFC][PATCH] swsusp: support creating bigger images
- References:
- [RFC][PATCH] swsusp: support creating bigger images
- From: "Rafael J. Wysocki" <[email protected]>
- Re: [RFC][PATCH] swsusp: support creating bigger images
- From: Nigel Cunningham <[email protected]>
- Re: [RFC][PATCH] swsusp: support creating bigger images
- From: "Rafael J. Wysocki" <[email protected]>
- [RFC][PATCH] swsusp: support creating bigger images
- Prev by Date: Re: [RFC][PATCH] swsusp: support creating bigger images
- Next by Date: Re: [RFC][PATCH] swsusp: support creating bigger images
- Previous by thread: Re: [RFC][PATCH] swsusp: support creating bigger images
- Next by thread: Re: [RFC][PATCH] swsusp: support creating bigger images
- Index(es):