> > Also if you want to really flush everything you should do a global
> > flush.
>
> That cr3 reload can probably be just removed, because swsusp is now
> stable...
I will remove it then.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hi!
> > + * TLB flush is purely and debugging attempt to make it fail fast if we
> > + * do something wrong. TLB is properly flushed in swsusp_restore.
>
> Did you measure it doesn't noticeable slow down suspend? CR3 reload is quite
> expensive, and doing it for each page is quite often.
It slow
> + * TLB flush is purely and debugging attempt to make it fail fast if we
> + * do something wrong. TLB is properly flushed in swsusp_restore.
Did you measure it doesn't noticeable slow down suspend? CR3 reload is quite
expensive, and doing it for each page is quite often.
Also if you want to re
Hi!
> > The following patch speeds up the restoring of swsusp images on x86-64
> > and makes the assembly code more readable (tested and works on AMD64). It's
> > against 2.6.11-rc1-mm1, but applies to 2.6.11-rc1-mm2. Please consifer for
> > applying.
> >
> > Signed-off-by: Rafael J. Wysocki <
On Thu, Jan 20, 2005 at 08:32:31PM +0100, Rafael J. Wysocki wrote:
> Hi,
>
> The following patch speeds up the restoring of swsusp images on x86-64
> and makes the assembly code more readable (tested and works on AMD64). It's
> against 2.6.11-rc1-mm1, but applies to 2.6.11-rc1-mm2. Please consif
> With this patch, at least 8 times less memory accesses are required to
> restore an image
> than without it, and in the original code cr3 is reloaded after copying each
> _byte_,
> let alone the SIB arithmetics. I'd expect it to be 10 times faster or so.
Probably more. CR3 reload is a seriali
On Friday, 21 of January 2005 13:32, Rafael J. Wysocki wrote:
> On Friday, 21 of January 2005 03:23, [EMAIL PROTECTED] wrote:
> > On Thu, Jan 20, 2005 at 10:46:37PM +0100, Rafael J. Wysocki wrote:
> > > On Thursday, 20 of January 2005 21:59, Pavel Machek wrote:
> > >
> > > Sure, but I think it's t
Hi!
> > Okay, it is still too big to merge directly. Would it be possible to
> > get mod_printk_progress(), introduce *_for_each (but leave there old
> > implementations), introduce pagedir_free() (but leave old
> > implementation). Better collision code should already be there, that
> > should ma
On Fri, Jan 21, 2005 at 02:42:54PM +0100, Rafael J. Wysocki wrote:
> Hi,
>
>
> No, it's "repeat until %ecx is zero or ZF is cleared", but the latter never
> happens
> with movsl. It's intended for cmpsl, scasl and friends (the assembler should
> complain about using it here).
>
> > I think thi
Hi,
On Friday, 21 of January 2005 11:30, Pavel Machek wrote:
> Hi!
>
> > Full patch still can get from
> > http://soulinfo.com/~hugang/swsusp/2005-1-21/
>
> From a short look:
>
> core.eatmem.diff of course helps, but is wrong. You should talk to
> akpm to find out why shrink_all_memory is not
On Friday, 21 of January 2005 11:06, Pavel Machek wrote:
> Hi!
>
> > > Well, I know that current code works. It was produced by C compiler,
> > > btw. Now, new code works for you, but it was not in kernel for 4
> > > releases, and... this code is pretty subtle.
> >
> > Now, I'm confused. :-) It'
On Friday, 21 of January 2005 03:23, [EMAIL PROTECTED] wrote:
> On Thu, Jan 20, 2005 at 10:46:37PM +0100, Rafael J. Wysocki wrote:
> > On Thursday, 20 of January 2005 21:59, Pavel Machek wrote:
> >
> > Sure, but I think it's there for a reason.
> >
> > > Anyway, this is likely to clash with hugan
Hi!
> Full patch still can get from
> http://soulinfo.com/~hugang/swsusp/2005-1-21/
>From a short look:
core.eatmem.diff of course helps, but is wrong. You should talk to
akpm to find out why shrink_all_memory is not doing its job.
i386: + repz movsl %ds:(%esi),%es:(%edi)
I do not think
> > +copyback_page:
> > + movq24(%rax), %r9
> > + xorl%r8d, %r8d
> > +
>
> Are you sure %r8 and %r9 are caller-saved? I'd use low registers if I
> were you, they look nincer and generate shorter opcodes ;-).
They are.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe
Hi!
> > Well, I know that current code works. It was produced by C compiler,
> > btw. Now, new code works for you, but it was not in kernel for 4
> > releases, and... this code is pretty subtle.
>
> Now, I'm confused. :-) It's roughly this:
>
> struct pbe *pbe = pagedir_nosave, *end;
> unsigned
Hi!
> > Sure, but I think it's there for a reason.
> >
> > > Anyway, this is likely to clash with hugang's work; I'd prefer this not
> > > to be applied.
> >
> > I am aware of that, but you are not going to merge the hugang's patches
> > soon, are you?
> > If necessary, I can change the patch
On Thu, Jan 20, 2005 at 10:46:37PM +0100, Rafael J. Wysocki wrote:
> On Thursday, 20 of January 2005 21:59, Pavel Machek wrote:
>
> Sure, but I think it's there for a reason.
>
> > Anyway, this is likely to clash with hugang's work; I'd prefer this not to
> > be applied.
>
> I am aware of that,
Hi,
On Friday, 21 of January 2005 00:06, Pavel Machek wrote:
> Hi!
>
> > > > The readability of code is also important, IMHO.
> > >
> > > It did not seem too much better to me.
> >
> > Well, the beauty is in the eye of the beholder. :-)
> >
> > Still, it shrinks the code (22 lines vs 37 lines)
Hi!
> > > The readability of code is also important, IMHO.
> >
> > It did not seem too much better to me.
>
> Well, the beauty is in the eye of the beholder. :-)
>
> Still, it shrinks the code (22 lines vs 37 lines), it uses less GPRs (5 vs
> 7), it uses less
> SIB arithmetics (0 vs 4 times),
Hi,
On Thursday, 20 of January 2005 23:06, Pavel Machek wrote:
> Hi!
>
> > > > The following patch speeds up the restoring of swsusp images on x86-64
> > > > and makes the assembly code more readable (tested and works on AMD64).
> > > > It's
> > > > against 2.6.11-rc1-mm1, but applies to 2.6.11
Hi!
> > > The following patch speeds up the restoring of swsusp images on x86-64
> > > and makes the assembly code more readable (tested and works on AMD64).
> > > It's
> > > against 2.6.11-rc1-mm1, but applies to 2.6.11-rc1-mm2. Please consifer
> > > for applying.
> >
> > Can you really meas
On Thursday, 20 of January 2005 21:59, Pavel Machek wrote:
> Hi!
>
> > The following patch speeds up the restoring of swsusp images on x86-64
> > and makes the assembly code more readable (tested and works on AMD64). It's
> > against 2.6.11-rc1-mm1, but applies to 2.6.11-rc1-mm2. Please consifer
Hi!
> The following patch speeds up the restoring of swsusp images on x86-64
> and makes the assembly code more readable (tested and works on AMD64). It's
> against 2.6.11-rc1-mm1, but applies to 2.6.11-rc1-mm2. Please consifer for
> applying.
Can you really measure the speedup? If you want ch
On Thursday, 20 of January 2005 20:32, Rafael J. Wysocki wrote:
> Hi,
>
> The following patch speeds up the restoring of swsusp images on x86-64
> and makes the assembly code more readable (tested and works on AMD64). It's
> against 2.6.11-rc1-mm1, but applies to 2.6.11-rc1-mm2. Please consifer
Hi,
The following patch speeds up the restoring of swsusp images on x86-64
and makes the assembly code more readable (tested and works on AMD64). It's
against 2.6.11-rc1-mm1, but applies to 2.6.11-rc1-mm2. Please consifer for
applying.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
25 matches
Mail list logo
