[lkml]   [2003]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PATCH: MTRR save and restore.

> I'd like to see the rest of this thread ;)
> > > > > We could add it to suspend scripts, but wouldn't mtrrs fit into the
> > > > > driver model idea? Would you say the same thing about implementing S3
> > > > > support?
> > > >
> > > > I think going through the driver model is the right thing to
> > > > do.
> > >
> > > It's useless bloat.
> What exactly is useless bloat? Based on the level of indentation, I'd
> assume that Richard said to elaborate?

Richard claims that MTRR save/restore is "useless bloat" and that it
can be don in userspace. He wants userland daemon to do it. I believe
that's bad idea (for reasons like suspend when battery low).

[This is what I said]
> > There's no helper daemon, nor I plan to make one. Notice that mtrr
> > stuff is shared between S3 (== suspend to ram) and swsusp. Both S3 and
> > swsusp can be used to do some pretty important stuff (machine
> > overheats or battery critically low -> suspend somewhere), so I do not
> > think userland daemon is good idea.
> >
> > It can be dependend on CONFIG_PM; if you still think that's too much
> > bloat, it could be dependend on CONFIG_SLEEP which could be only
> > compiled when S3 or swsusp is selected (but I feel that would be
> > overdesign).
> Yes, that's too much.
> MTRRs are one interface to an x86 CPU. CPUs are already represented in the
> device tree. The proper thing to do would be to have the CPU suspend/
> resume methods save and restore the MTRRs. It still requires an #ifdef in
> the CPU code, but with a little work, could be massaged down a ways.

Yep, agreed, mtrrs need in-kernel save/restore support.
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:34    [W:0.082 / U:34.004 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site