Date: Thu, 25 Mar 2004 16:01:29 +0100
From: Pavel Machek <pavel@suse.cz>
To: Jens Axboe <axboe@suse.de>
Cc: Pavel Machek <pavel@suse.cz>, kernel list <linux-kernel@vger.kernel.org>,
       seife@suse.de
Subject: Re: swsusp with highmem, testing wanted
Message-ID: <20040325150129.GI1505@openzaurus.ucw.cz>
References: <20040324235702.GA497@elf.ucw.cz> <20040325073244.GE3377@suse.de> <20040325115129.GB300@elf.ucw.cz> <20040325121418.GK3377@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040325121418.GK3377@suse.de>
User-Agent: Mutt/1.3.27i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1334
Lines: 38

Hi!

> > I actually ran it on real 2GB machine, and it seemed to do the trick,
> > unless "too much" memory was full.
> 
> Well your patch really looked nothing more than a nasty hack, since it
> has known and very real failures. Why do you need to copy all highmem
> down to low mem? That cannot _ever_ work reliably?!

Because it is only solution I know that does not require rewriting half
the kernel or rewriting all the block drivers. (see how swsusp already
does copy of lowmem).

Having special "poll" mode for block drivers might do the trick, but thats lot of work.

Which operations are allowed to access highmem? Can I rely on
block device read/write not accessing highmem?

> > What wories me is 
> > 
> > +               kaddr = kmap_atomic(page, KM_USER0);
> > +               memcpy(save->data, kaddr, PAGE_SIZE);
> > +               kunmap_atomic(kaddr, KM_USER0);
> > 
> > : am I allowed to use KM_USER0, or should I get new KM_constant just
> > for me?
> 
> KM_USER0 should be fine.

Thanks.
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/