Hi. On Friday 10 February 2006 09:34, Pavel Machek wrote: > Hi! > > > > > Any changes to userspace are a fair game. OTOH kernel provides linear > > > > image to be saved to userspace, and what it uses internally should > > > > not be important to userland parts. (And Rafael did some changes in > > > > that area to make it more effective, IIRC). > > > > > > Yes. The code is now split into the part that handles the snapshot > > > image (in snapshot.c) and the part that writes/reads it to swap (in > > > swap.c). [I'm referring to recent -mm kernels.] > > > > > > The access to the snapshot image is provided via the functions > > > snapshot_write_next() and snapshot_read_next() that are called by the > > > code in swap.c and may be used by the user space tools via the > > > interface in user.c. In principle it ought to be possible to plug > > > something else instead of the code in snapshot.c without > > > breaking the rest. > > > > So, what is the answer then? If I submitted patches to provide the > > possibility of separating LRU pages into a separate stream of pages to be > > read/written, would it have any chance of getting merged? (Along with > > other patches to make writing a full image of memory possible). > > Could we do the other stuff, first, please? Userland > LZF/encryption/progress should be easy to do, and doing that should > teach us how to cooperate. The problem I have with doing that is that it makes more work. Adding support for multiple sets of pages is a more fundamental change, and so should be done earlier. Let me use an analogy from evolutionary theory (yes, I think evolution is flawed, but let's ignore that for the mo). If you were trying to image the steps by which an amoeba became a human being, would you put the devlopment of the cardio-vascular system before the development of eye sight? Making eye sight work (if it was at all possible) without a cardio vascular system would result in a fundamentally different design for the eye than if you did the cario-vascular system first. Changing the eye once the cardio-vascular system was in would be a huge redevelopment, and a huge pain. For the same reasons, I think that if support for 2 pagesets was going to be put in an implementation it should be done as early as possible. Likewise for reworking the method by which data is stored (I say, thinking of bitmaps vs pbes). Regards, Nigel -- See our web page for Howtos, FAQs, the Wiki and mailing list info. http://www.suspend2.net IRC: #suspend2 on Freenode
Attachment:
pgpWgTgPgvdaP.pgp
Description: PGP signature
- Follow-Ups:
- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- From: "Rafael J. Wysocki" <[email protected]>
- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- References:
- [ 00/10] [Suspend2] Modules support.
- From: Nigel Cunningham <[email protected]>
- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- From: Nigel Cunningham <[email protected]>
- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- From: Pavel Machek <[email protected]>
- [ 00/10] [Suspend2] Modules support.
- Prev by Date: Re: [PATCH] mm: Implement Swap Prefetching v22
- Next by Date: Re: PROBLEM: kernel BUG at mm/rmap.c:486 - kernel 2.6.15-r1
- Previous by thread: Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- Next by thread: Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- Index(es):