Hi! > > > I can agree with putting splash screens and userspace stuff in > > > userspace. Suspend2 has had that too, since March. But the guts of > > > the > > > > Well, I'd say that having to resort to netlink is ... not quite > > nice. You get all the complexity of having userspace running during > > suspend, and get very little benefit. > > Mmm, but less complexity than with trying to do the whole suspend from > userspace. (I don't need to export pageflags, bio routines etc or work > around it by using /dev/kmem). Well, userland swsusp has pretty low impact on kernel code -- it adds something like 150 lines: drivers/char/mem.c | 42 + include/linux/suspend.h | 23 kernel/power/console.c | 1 kernel/power/disk.c | 19 kernel/power/swsusp.c | 78 + usr/swsusp-init | 9 8 files changed, 2696 insertions(+), 4 deletions(-) i don't think you can do much better than that... > > ...at expense of complexity, and hooks all over the kernel. Yes, if > > you modify kernel a bit, nothing will use the page cache. > > Could you back your "hooks all over the kernel" statement up? I do have > some BUG_ON()s aimed at double checking that nothing bad happens, but > they never get hit and obviously aren't required to stop processes using > the page cache. All that's really required is to freeze processes. Are you willing to merge the code without BUG_ONs? > > Anyway, I believe we have solution for that one. See Rafael's recent > > patches -- "only free as much memory as neccessary" should do the > > trick, without excessive complexity. > > That's still imposing a 1/2 of memory limit, though. Yes, hopefully users will not notice. > > Well, I do not want the complexity of two page sets. I think Rafael's > > patches will provide almost equivalent functionality. Other than that, > > all your features should be doable. I'm not saying I'm going to write > > those patches myself, but I'll certainly not reject them just because > > they are too big. > > I'm sorry for making you think that having two pagesets is a complex > issues. I know that when I first did it, I put tight restrictions on > memory usage while the first pageset was written and used a separate > memory pool. Since then, I've realised a far simpler way of handling > this, and the code has been greatly simplified. In essence, all you need > to do is make your I/O code generic enough that it can be passed a list > of pages to write and put page cache pages in a separate list when > figuring out what pages need to be saved. Then you save those pages > before doing your atomic copy of the other pages, and reload them after > restoring the atomic copy at resume time. Okay, it may have gotten better. Anyway, this is the only part that really needs to be in-kernel. Saving 50% of memory is still going to produce *way* more responsive system than "save as little as possible", and I hope it will be good enough. Pavel -- Thanks, Sharp!
