[PATCH] GEODE: decouple sleep/resume from powerdown/powerup (take 2)

[Bernardo Innocenti]

This patch merges the fb_powerup and fb_powerdown hooks in a single
operation fb_power with an additional "state" parameter ranging
from 0 (running) to 3 (poweroff).

The geodefb uses state 2 as an intermediate low-power mode, where
the LX or GX video unit is turned off, but the GPU may still be working.
Notably, the GPU register set does not get overwritten when resuming
to state 0, so the system can safely keep using the GPU while in state 2.
The DCON driver now uses this new suspend state to let the X server draw
in the background while the screen frozen.

This fixes the rather amusing OLPC bug #3603 that made the toolbar icons
come up tinted in green when "pretty boot" was enabled.  Tested on both
B2 (GX) and B3 (LX) machines.  Both the freeze/unfreeze and suspend/resume
codepaths work as expected.

This second revision ensures the GX registers are saved in both the
suspend and powerdown cases, otherwise we restore stale register state
when we unfreeze.

Signed-off-by: Bernardo Innocenti <[EMAIL PROTECTED]>
---
 drivers/video/fbmem.c   |   47 +--
 drivers/video/geode/geodefb.h   |   13 +++--
 drivers/video/geode/gxfb_core.c |   17 +++
 drivers/video/geode/lxfb.h  |3 +-
 drivers/video/geode/lxfb_core.c |   12 ++---
 drivers/video/geode/lxfb_ops.c  |   47 
 drivers/video/geode/video_gx.c  |   94 --
 drivers/video/geode/video_gx.h  |3 +-
 drivers/video/olpc_dcon.c   |8 ++--
 include/linux/fb.h  |7 +--
 10 files changed, 110 insertions(+), 141 deletions(-)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 61d7659..51c9f79 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -736,49 +736,28 @@ static void try_to_load(int fb)
 #endif /* CONFIG_KMOD */
 
 int
-fb_powerup(struct fb_info *info)
+fb_power(struct fb_info *info, int state)
 {
int ret = 0;
 
-   if (!info || info->state == FBINFO_STATE_RUNNING)
-   return 0;
-
-   if (info->fbops->fb_powerup)
-   ret = info->fbops->fb_powerup(info);
-
-   if (!ret) {
-   acquire_console_sem();
-   fb_set_suspend(info, 0);
-   release_console_sem();
-   }
-
-   return ret;
-}
-
-int
-fb_powerdown(struct fb_info *info)
-{
-   int ret = 0;
-
-   if (!info || info->state == FBINFO_STATE_SUSPENDED)
-   return 0;
+   if (state < 0 || state > 3)
+   return -EINVAL;
 
-   /* Tell everybody that the fbdev is going down */
acquire_console_sem();
-   fb_set_suspend(info, 1);
-   release_console_sem();
+   /* Powerdown? */
+   if (state == 3 && info->state != FBINFO_STATE_SUSPENDED)
+   /* Tell everybody that the fbdev is going down */
+   fb_set_suspend(info, 1);
 
-   if (info->fbops->fb_powerdown)
-   ret = info->fbops->fb_powerdown(info);
+   if (info->fbops->fb_power)
+   ret = info->fbops->fb_power(info, state);
 
-   /* If the power down failed, then un-notify */
-
-   if (ret) {
-   acquire_console_sem();
+   /* Power down failed, or powerup succeeded? */
+   if (((state == 3 && ret) || !ret) && (info->state != 
FBINFO_STATE_RUNNING))
+   /* Tell everybody that the fbdev is back up */
fb_set_suspend(info, 0);
-   release_console_sem();
-   }
 
+   release_console_sem();
return ret;
 }
 
diff --git a/drivers/video/geode/geodefb.h b/drivers/video/geode/geodefb.h
index 0214d11..cd1ce6e 100644
--- a/drivers/video/geode/geodefb.h
+++ b/drivers/video/geode/geodefb.h
@@ -12,12 +12,14 @@
 #ifndef __GEODEFB_H__
 #define __GEODEFB_H__
 
-#define FB_POWER_STATE_OFF  0
-#define FB_POWER_STATE_SUSPEND  1
-#define FB_POWER_STATE_ON   2
-
 struct geodefb_info;
 
+/* For geodefb_par->power_state */
+#define FB_POWER_STATE_OFF  3
+#define FB_POWER_STATE_SUSPEND  2
+#define FB_POWER_STATE_UNUSED   1 /* Reserved */
+#define FB_POWER_STATE_ON   0
+
 struct geode_dc_ops {
void (*set_mode)(struct fb_info *);
void (*set_palette_reg)(struct fb_info *, unsigned, unsigned, unsigned, 
unsigned);
@@ -42,7 +44,8 @@ struct geodefb_par {
struct geode_dc_ops  *dc_ops;
struct geode_vid_ops *vid_ops;
 
-   int state;
+   /* See FB_POWER_STATE_* definitions above */
+   int power_state;
 };
 
 #endif /* !__GEODEFB_H__ */
diff --git a/drivers/video/geode/gxfb_core.c b/drivers/video/geode/gxfb_core.c
index 3eabc53..cd43c8e 100644
--- a/drivers/video/geode/gxfb_core.c
+++ b/drivers/video/geode/gxfb_core.c
@@ -383,8 +383,7 @@ static struct fb_ops gxfb_ops = {
.fb_fillrect= cfb_fillrect,
.fb_copyarea= cfb_copyarea,
.fb_imageblit   = cfb_imageblit,
-   .fb_powerdown   = gxfb_powerdown,
-   .fb_powerup = gxfb_powerup,
+   .fb_power   = gxfb_power,
 };
 
 static struct

Re: Modification of Public OLPC Software

[James Cameron]

On Mon, Sep 24, 2007 at 10:19:01PM -0700, big one wrote:
> Because OLPC is sold to general public using "Buy 2 Get 1" G1G1,

The answers below are unrelated to the fact that it is being sold.

> is it possible to customize OLPC:

XO-1 is the identifier for the hardware, OLPC is the identifier for the
project.

> 1. Disable internal Flash Drive, 

No.  But if it did not contain the essential boot components (such as
/boot/olpc.fth) it would be ignored, and so you would have the same net
effect.

> and boot from external USB hard disk

Yes.  The external USB storage would need to have the essential boot
components (such as /boot/olpc.fth).  This is how we load new versions
at the moment.

> / external CD-ROM drive.

Don't know.  A PC boot structure would not work, only the XO specific
boot structure would work.  I've not tested it, and I don't know if
anyone has.

> 2. Boot to console mode (svgalib).

Not sure.  I think not.  Let us know how it goes, we're curious.  The XO
kernel has framebuffer support for the LCD.  Suggest you use that
instead.  Try it in emulation now.

> 3. Install Fedora, Mandriva or other Linux/BSD distro, FreeDOS.

Only if those distributions add support for XO, or if you add the
support yourself.  For example we have a way to install Debian
documented on the Wiki.  As Bernardo has said, minimum capability would
be the Linux kernel patched and built for XO.  The kernel built for
ordinary PC is not appropriate.  Many services provided by a PC BIOS are
not provided by the XO firmware.

> Use TWM / IceWM windows manager.

Yes, that works fine, once the barriers above are overcome.

> Is the above ideas possible?

Yes, with work.  Let us know how you go.  It isn't part of OLPC mission
though, and now is not the time for us to concentrate on it.

-- 
James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [PATCH] GEODE: decouple sleep/resume from powerdown/powerup (take 2)

[Bernardo Innocenti]

Andres Salomon wrote:

>> diff --git a/drivers/video/geode/lxfb_ops.c b/drivers/video/geode/lxfb_ops.c
>> index b2ecb4d..b380238 100644
>> --- a/drivers/video/geode/lxfb_ops.c
>> +++ b/drivers/video/geode/lxfb_ops.c
>> @@ -829,33 +829,42 @@ static void lx_restore_regs(struct fb_info *info, 
>> struct geoderegs *regs)
> [...]
>> -int lx_shutdown(struct fb_info *info)
>> +int lx_power(struct fb_info *info, int state)
>>  {
>>  struct lxfb_par *par = info->par;
>>  
>> -if (lx_power_on == 0)
>> -return 0;
>> -
>> -writel(DC_UNLOCK_CODE, par->dc_regs + DC_UNLOCK);
>> -lx_save_regs(info, &saved_regs);
>> -lx_graphics_disable(info);
>> +if (state < 0 || state > 3)
>> +return -EINVAL;
>>  
>> -lx_power_on = 0;
>> -return 0;
>> -}
>> +/* Going into power save */
>> +if (state >= 2 && lx_power_state < 2)
>> +lx_graphics_disable(info);
>>  
>> -int lx_powerup(struct fb_info *info)
>> -{
>> -struct lxfb_par *par = info->par;
>> +/* Powering down */
>> +if (state >= 3 && lx_power_state < 3) {
>> +writel(DC_UNLOCK_CODE, par->dc_regs + DC_UNLOCK);
>> +lx_save_regs(info, &saved_regs);
>> +}
>>  
>> -if (lx_power_on == 1)
>> -return 0;
>> +/* Restoring from power save */
>> +if (state < 3 && lx_power_state >= 3) {
>> +lx_restore_regs(info, &saved_regs);
>> +writel(0, par->dc_regs + DC_UNLOCK);
>> +}
>>  
>> -lx_restore_regs(info, &saved_regs);
>> -writel(0, par->dc_regs + DC_UNLOCK);
>> +/* Powering up */
>> +if (state < 2 && lx_power_state >= 2)
>> +lx_graphics_enable(info);
>>  
>> -lx_power_on = 1;
>> +lx_power_state = state;
>>  return 0;
> 
> 
> Jordan claims that we don't want to be calling lx_{save,restore}_regs
> for state 2...  I'll let him explain.

We aren't doing that already.

We save registers only on the transition from 2 to 3 and we restore them
when we go back from 3 to 2.

On the GX, we *save* them always and restore them only on powerup.
Saving the registers is needed because, later on, we peek a few values
from that structure for powering up the video unit.


> Jordan and I discussed using fb_blank() rather than adding an additional API.

Was it on IRC or email?  Could you please forward it to me?


> Basically, my feeling is that fb_blank is already doing (or should be doing)
> what we want to be doing (disabling misc hardware bits that are not needed
> when the video processor is no longer pulling images from the GPU).  So, we
> might as well just be calling fb_blank from the dcon's sleep/freeze functions.
> Jordan prefers the fb_power* stuff.  We can argue about it later, with
> upstream.

Using the fb_blank() interface seems like a very good idea to me.  The different
kinds of blanking can be mapped to DCON freeze, video off, and complete 
poweroff.

This rework will take some time.  Could we push it after Trial3?  For now, I see
this patch as a quick bugfix only.  And the change brings the fb_power() API
somewhat *closer* to what would be needed for switching to fb_


> Also, the fb_power() API really needs a stricter definition of power levels.

I looked into pci_power_t and it looks close to what we need:

 #define PCI_D0  ((pci_power_t __force) 0)
 #define PCI_D1  ((pci_power_t __force) 1)
 #define PCI_D2  ((pci_power_t __force) 2)
 #define PCI_D3hot   ((pci_power_t __force) 3)
 #define PCI_D3cold  ((pci_power_t __force) 4)
 #define PCI_UNKNOWN ((pci_power_t __force) 5)
 #define PCI_POWER_ERROR ((pci_power_t __force) -1)

But this change will have to be undone later if we move to fb_blank().
To save time, couldn't we just elide it?

-- 
 \___/
 |___|  Bernardo Innocenti - http://www.codewiz.org/
  \___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #3631 HIGH First D: Need fullscreen mode

[Albert Cahalan]

Eben Eliason writes:

> It will actually toggle both the toolbar and a tray (if present).
> Moreover, it can be configured by the activity such that it might
> actually expand a smaller section of the screen, and not simply hide
> the toolbars.  For instance, in Record the fullscreen button resides
> within the video feed, to indicate that only the video will appear in
> fullscreen mode. It's not only a toggle for the toolbar, but a broader
> concept which can be interpreted as necessary by each activity.
>
> I'm open to other suggestions for shortcuts, though.

Please go with the Alt-Enter suggestion.

More importantly, do not let Sugar steal any Ctrl- keystrokes
from apps. Ctrl-F is "Find" in lots of things. I just noticed
it being used in XChat. It's used in xpdf. It's used in Firefox.
Ctrl- keystrokes in general are taken by both GUI and terminal
apps already.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Modification of Public OLPC Software

[Bernardo Innocenti]

big one wrote:

> I often use Linux without any X-Windows, but only svgalib: mplayer, links 2.0 
> browser, mp3blaster, etc. On FreeDOS (Free Disk Operating System), I can use 
> display, arachne, pppd etc.
> 
> Because OLPC is sold to general public using "Buy 2 Get 1" G1G1, is it 
> possible to customize OLPC:
> 1. Disable internal Flash Drive, and boot from external USB hard disk / 
> external CD-ROM drive.
> 2. Boot to console mode (svgalib).
> 3. Install Fedora, Mandriva or other Linux/BSD distro, FreeDOS. Use TWM / 
> IceWM windows manager.
> Is the above ideas possible?

3 is possible provided you replace the standard Linux kernel with one including
the OLPC patch set.  I've also been told that Minix works.

I doubt the BSDs already support our hardware, but wouldn't be hard. FreeDOS 
would
be problematic because the OFW does not emulate BIOS services and does not 
provide
16bit support.  But maybe you can get LinuxBIOS to boot from OFW and then you're
done!

Several people booted regular Fedora 7 and Ubuntu Feisty off USB drives.  I 
think
the only change needed was installing the kernel package.  The RPM is available
from us, a dpkg should be easy to produce with the Debian kernel development 
tools.

When enough of our patches will be merged upstream, and the OLPC hardware gets 
more
widely available, I'd expect the mainstream distros to offer out of the box OLPC
support.

-- 
 \___/
 |___|  Bernardo Innocenti - http://www.codewiz.org/
  \___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Modification of Public OLPC Software

[Mitch Bradley]

OLPC does not have a conventional BIOS, so any software that depends on 
one will not work.

big one wrote:
> I often use Linux without any X-Windows, but only svgalib: mplayer, links 2.0 
> browser, mp3blaster, etc. On FreeDOS (Free Disk Operating System), I can use 
> display, arachne, pppd etc.
>
> Because OLPC is sold to general public using "Buy 2 Get 1" G1G1, is it 
> possible to customize OLPC:
> 1. Disable internal Flash Drive, and boot from external USB hard disk / 
> external CD-ROM drive.
> 2. Boot to console mode (svgalib).
> 3. Install Fedora, Mandriva or other Linux/BSD distro, FreeDOS. Use TWM / 
> IceWM windows manager.
> Is the above ideas possible?
> Thank you.
>
> _
> = You want FREE web-based email ? 
> = You want your own @qon.lao.net address??
> = Then you want LaoNet's WebMail !
> = Get it at http://webmail.lao.net !!
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>   

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Modification of Public OLPC Software

[big one]

I often use Linux without any X-Windows, but only svgalib: mplayer, links 2.0 
browser, mp3blaster, etc. On FreeDOS (Free Disk Operating System), I can use 
display, arachne, pppd etc.

Because OLPC is sold to general public using "Buy 2 Get 1" G1G1, is it possible 
to customize OLPC:
1. Disable internal Flash Drive, and boot from external USB hard disk / 
external CD-ROM drive.
2. Boot to console mode (svgalib).
3. Install Fedora, Mandriva or other Linux/BSD distro, FreeDOS. Use TWM / IceWM 
windows manager.
Is the above ideas possible?
Thank you.

_
= You want FREE web-based email ? 
= You want your own @qon.lao.net address??
= Then you want LaoNet's WebMail !
= Get it at http://webmail.lao.net !!
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #3631 HIGH First D: Need fullscreen mode

[Ivo Emanuel Gonçalves]

On 9/25/07, Eben Eliason <[EMAIL PROTECTED]> wrote:
> I'm open to other suggestions for shortcuts, though.

What about the F8 key, or whatever's the name of the largest dot key
at the top of the keyboard?

Right now, it doesn't seem to do anything.

-Ivo
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Fwd: + maps-pssproportional-set-size-accounting-in-smaps.patch added to -mm tree]

[Bernardo Innocenti]

On 09/24/2007 05:14 PM, Dan Winship wrote:

> The biggest problem the ring has right now is that it doesn't take into 
> account the fact that code pages can be swapped back out to disk to 
> create more RAM, and so it needs to count inactive pages differently 
> from active pages if we want the free-space wedge in the donut to be an 
> accurate estimation of the user's ability to launch another activity. 
> AFAIK the PSS kernel patch doesn't help with this.

Considering only active pages would be an unfair estimate of the overall
memory pressure caused by a running activity.  An activity in the
background would seem to use less memory than one in the foreground.
And the usage estimate would change over time without the application
ever allocating more.

-- 
 \___/
 |___|  Bernardo Innocenti - http://www.codewiz.org/
  \___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #3631 HIGH First D: Need fullscreen mode

[Eben Eliason]

It will actually toggle both the toolbar and a tray (if present).
Moreover, it can be configured by the activity such that it might
actually expand a smaller section of the screen, and not simply hide
the toolbars.  For instance, in Record the fullscreen button resides
within the video feed, to indicate that only the video will appear in
fullscreen mode. It's not only a toggle for the toolbar, but a broader
concept which can be interpreted as necessary by each activity.

I'm open to other suggestions for shortcuts, though.

- Eben


On 9/24/07, Bert Freudenberg <[EMAIL PROTECTED]> wrote:
> Maybe Alt-Enter comes from Windows, I'm not sure. It's used by
> Parallels, too (or did I configure it that way?)
>
> Anyway ... "full-screen" seems odd anyway because it just toggles the
> toolbar. How about Ctrl-T then?
>
>
> - Bert -
>
>
> On Sep 25, 2007, at 0:56 , Eben Eliason wrote:
>
> > Well, some of our principles for keyboard shortcuts have been 1)
> > treating CTRL-K as a primary shortcut for action A and ALT-K as a
> > variation on that same action and 2) we've been trying to adhere to
> > the (generally similar) shortcut paradigms present in Linux and OSX
> > when possible.
> >
> > I'm not as familiar with Linux, but OSX frequently uses F for
> > fullscreen.  Is ALT-ENTER  of Windows origin?
> >
> > On 9/24/07, Zarro Boogs per Child <[EMAIL PROTECTED]> wrote:
> >> #3631: Need fullscreen mode
> >> --
> >> +-
> >>   Reporter:  Eben |   Owner:  erikos
> >>   Type:  task |  Status:  new
> >>   Priority:  high |   Milestone:  First Deployment, V1.0
> >>  Component:  web browser  | Version:
> >> Resolution:   |Keywords:
> >>   Verified:  0|
> >> --
> >> +-
> >>
> >> Comment(by bert):
> >>
> >>  Traditionally, Alt-Enter is used for toggling full-screen mode. I
> >> like
> >>  that better than using up a valuable ctrl-key combo, which should
> >> be left
> >>  to the activities. Etoys for one already uses all of them (if you
> >> disable
> >>  the "novice mode" at least).
>
>
>
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #3631 HIGH First D: Need fullscreen mode

[Bert Freudenberg]

Maybe Alt-Enter comes from Windows, I'm not sure. It's used by  
Parallels, too (or did I configure it that way?)

Anyway ... "full-screen" seems odd anyway because it just toggles the  
toolbar. How about Ctrl-T then?


- Bert -


On Sep 25, 2007, at 0:56 , Eben Eliason wrote:

> Well, some of our principles for keyboard shortcuts have been 1)
> treating CTRL-K as a primary shortcut for action A and ALT-K as a
> variation on that same action and 2) we've been trying to adhere to
> the (generally similar) shortcut paradigms present in Linux and OSX
> when possible.
>
> I'm not as familiar with Linux, but OSX frequently uses F for
> fullscreen.  Is ALT-ENTER  of Windows origin?
>
> On 9/24/07, Zarro Boogs per Child <[EMAIL PROTECTED]> wrote:
>> #3631: Need fullscreen mode
>> -- 
>> +-
>>   Reporter:  Eben |   Owner:  erikos
>>   Type:  task |  Status:  new
>>   Priority:  high |   Milestone:  First Deployment, V1.0
>>  Component:  web browser  | Version:
>> Resolution:   |Keywords:
>>   Verified:  0|
>> -- 
>> +-
>>
>> Comment(by bert):
>>
>>  Traditionally, Alt-Enter is used for toggling full-screen mode. I  
>> like
>>  that better than using up a valuable ctrl-key combo, which should  
>> be left
>>  to the activities. Etoys for one already uses all of them (if you  
>> disable
>>  the "novice mode" at least).




___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #3631 HIGH First D: Need fullscreen mode

[Eben Eliason]

Well, some of our principles for keyboard shortcuts have been 1)
treating CTRL-K as a primary shortcut for action A and ALT-K as a
variation on that same action and 2) we've been trying to adhere to
the (generally similar) shortcut paradigms present in Linux and OSX
when possible.

I'm not as familiar with Linux, but OSX frequently uses F for
fullscreen.  Is ALT-ENTER  of Windows origin?

On 9/24/07, Zarro Boogs per Child <[EMAIL PROTECTED]> wrote:
> #3631: Need fullscreen mode
> --+-
>   Reporter:  Eben |   Owner:  erikos
>   Type:  task |  Status:  new
>   Priority:  high |   Milestone:  First Deployment, V1.0
>  Component:  web browser  | Version:
> Resolution:   |Keywords:
>   Verified:  0|
> --+-
>
> Comment(by bert):
>
>  Traditionally, Alt-Enter is used for toggling full-screen mode. I like
>  that better than using up a valuable ctrl-key combo, which should be left
>  to the activities. Etoys for one already uses all of them (if you disable
>  the "novice mode" at least).
>
> --
> Ticket URL: 
> One Laptop Per Child 
> OLPC bug tracking system
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Fwd: + maps-pssproportional-set-size-accounting-in-smaps.patch added to -mm tree]

[Dan Winship]

Andres Salomon wrote:
> On Mon, 24 Sep 2007 16:51:07 -0400
> Bernardo Innocenti <[EMAIL PROTECTED]> wrote:
> 
>> Cool!  Andrew picked up the patch I liked.
>>
>> Andres, how about adding it to olpc-2.6 too?  Along with the
>> latest Memphis patch, it would give use us invaluable stats
>> for those trying to reduce memory usage.
>>
> 
> Is it useful for the sugar folks' memory donut?  I'm certainly not opposed
> to including the patch (though I'd want to look over the lkml thread before
> committing), if people find it useful.

"PSS" is basically the same measure we're currently calculating (a 
little more accurate in some ways, a little less in others). Having the 
kernel calculate PSS would let us draw the ring faster (which would be 
good), but wouldn't affect the accuracy.

The biggest problem the ring has right now is that it doesn't take into 
account the fact that code pages can be swapped back out to disk to 
create more RAM, and so it needs to count inactive pages differently 
from active pages if we want the free-space wedge in the donut to be an 
accurate estimation of the user's ability to launch another activity. 
AFAIK the PSS kernel patch doesn't help with this.

-- Dan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Fwd: + maps-pssproportional-set-size-accounting-in-smaps.patch added to -mm tree]

[Andres Salomon]

On Mon, 24 Sep 2007 16:51:07 -0400
Bernardo Innocenti <[EMAIL PROTECTED]> wrote:

> Cool!  Andrew picked up the patch I liked.
> 
> Andres, how about adding it to olpc-2.6 too?  Along with the
> latest Memphis patch, it would give use us invaluable stats
> for those trying to reduce memory usage.
> 

Is it useful for the sugar folks' memory donut?  I'm certainly not opposed
to including the patch (though I'd want to look over the lkml thread before
committing), if people find it useful.


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

[Fwd: + maps-pssproportional-set-size-accounting-in-smaps.patch added to -mm tree]

[Bernardo Innocenti]

Cool!  Andrew picked up the patch I liked.

Andres, how about adding it to olpc-2.6 too?  Along with the
latest Memphis patch, it would give use us invaluable stats
for those trying to reduce memory usage.


 Original Message 
Subject: + maps-pssproportional-set-size-accounting-in-smaps.patch added to -mm 
tree
Date: Mon, 24 Sep 2007 13:32:10 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL 
PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], 
[EMAIL PROTECTED]


The patch titled
 maps: PSS(proportional set size) accounting in smaps
has been added to the -mm tree.  Its filename is
 maps-pssproportional-set-size-accounting-in-smaps.patch

*** Remember to use Documentation/SubmitChecklist when testing your code ***

See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this

--
Subject: maps: PSS(proportional set size) accounting in smaps
From: Fengguang Wu <[EMAIL PROTECTED]>

The "proportional set size" (PSS) of a process is the count of pages it has
in memory, where each page is divided by the number of processes sharing
it.  So if a process has 1000 pages all to itself, and 1000 shared with one
other process, its PSS will be 1500.

   - lwn.net: "ELC: How much memory are applications really using?"

The PSS proposed by Matt Mackall is a very nice metic for measuring an
process's memory footprint.  So collect and export it via
/proc//smaps.

Matt Mackall's pagemap/kpagemap and John Berthels's exmap can also do the
job.  They are comprehensive tools.  But for PSS, let's do it in the simple
way.

Cc: John Berthels <[EMAIL PROTECTED]>
Cc: Bernardo Innocenti <[EMAIL PROTECTED]>
Cc: Padraig Brady <[EMAIL PROTECTED]>
Cc: Denys Vlasenko <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Acked-by: Matt Mackall <[EMAIL PROTECTED]>
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
Cc: Hugh Dickins <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---

 fs/proc/task_mmu.c |   29 -
 1 files changed, 28 insertions(+), 1 deletion(-)

diff -puN fs/proc/task_mmu.c~maps-pssproportional-set-size-accounting-in-smaps 
fs/proc/task_mmu.c
--- a/fs/proc/task_mmu.c~maps-pssproportional-set-size-accounting-in-smaps
+++ a/fs/proc/task_mmu.c
@@ -324,6 +324,27 @@ struct mem_size_stats
unsigned long private_clean;
unsigned long private_dirty;
unsigned long referenced;
+
+   /*
+* Proportional Set Size(PSS): my share of RSS.
+*
+* PSS of a process is the count of pages it has in memory, where each
+* page is divided by the number of processes sharing it.  So if a
+* process has 1000 pages all to itself, and 1000 shared with one other
+* process, its PSS will be 1500.   - Matt Mackall, lwn.net
+*/
+   u64   pss;
+   /*
+* To keep (accumulated) division errors low, we adopt 64bit pss and
+* use some low bits for division errors. So (pss >> PSS_DIV_BITS)
+* would be the real byte count.
+*
+* A shift of 12 before division means(assuming 4K page size):
+*  - 1M 3-user-pages add up to 8KB errors;
+*  - supports mapcount up to 2^24, or 16M;
+*  - supports PSS up to 2^52 bytes, or 4PB.
+*/
+#define PSS_DIV_BITS   12
 };
 
 struct smaps_arg
@@ -341,6 +362,7 @@ static int smaps_pte_range(pmd_t *pmd, u
pte_t *pte, ptent;
spinlock_t *ptl;
struct page *page;
+   int mapcount;
 
pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
for (; addr != end; pte++, addr += PAGE_SIZE) {
@@ -357,16 +379,19 @@ static int smaps_pte_range(pmd_t *pmd, u
/* Accumulate the size in pages that have been accessed. */
if (pte_young(ptent) || PageReferenced(page))
mss->referenced += PAGE_SIZE;
-   if (page_mapcount(page) >= 2) {
+   mapcount = page_mapcount(page);
+   if (mapcount >= 2) {
if (pte_dirty(ptent))
mss->shared_dirty += PAGE_SIZE;
else
mss->shared_clean += PAGE_SIZE;
+   mss->pss += (PAGE_SIZE << PSS_DIV_BITS) / mapcount;
} else {
if (pte_dirty(ptent))
mss->private_dirty += PAGE_SIZE;
else
mss->private_clean += PAGE_SIZE;
+   mss->pss += (PAGE_SIZE << PSS_DIV_BITS);
}
}
pte_unmap_unlock(pte - 1, ptl);
@@ -395,6 +420,7 @@ static int show_smap(struct seq_file *m,
seq_printf(m,
   "Size:   %8lu kB\n"
   

Less Watts

[Bernardo Innocenti]

FYI: http://www.lesswatts.org/

-- 
 \___/
 |___|  Bernardo Innocenti - http://www.codewiz.org/
  \___\ One Laptop Per Child - http://www.laptop.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Increasing performance by tuning swappiness

[Dan Winship]

Chris Ball wrote:
> Hi,
> 
>> Any thoughts on this subject?
> 
> Yes:  we don't use swap.

Not quite; we don't have anywhere to swap *dirty* pages to, but the 
kernel can still swap out shared library code pages and stuff like that, 
because they already exist on disk so it can just read them back from 
there if it needs them later.

-- Dan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Increasing performance by tuning swappiness

[Ivo Emanuel Gonçalves]

On 9/24/07, Chris Ball <[EMAIL PROTECTED]> wrote:
> we don't use swap.

Wow.  I never noticed it.

However, when it comes to that, it makes perfect sense; in a
flash-based medium, it would not be appropriate to waste precious
writing cycles with swap memory.

Sorry for wasting your time.

-Ivo
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Increasing performance by tuning swappiness

[Chris Ball]

Hi,

   > Any thoughts on this subject?

Yes:  we don't use swap.

- Chris.
-- 
Chris Ball   <[EMAIL PROTECTED]>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Increasing performance by tuning swappiness

[Ivo Emanuel Gonçalves]

Swappiness[1] is believed to increase perfomance by setting the amount
of RAM an application may use before switching to swap.

The following command:
# cat /proc/sys/vm/swappiness
reports that the XO distro is using 60 as the current value.

A specific value may be set as the default in /etc/sysctl.conf
Example: vm.swappiness = 70

The question is, would using another value here increase performance?
I think so.  It's a matter of finding what is the better value and,
considering the hardware will remain pretty much the same from here
on, it is likely worthy to set something according to the laptop's
needs.

Any thoughts on this subject?

-Ivo

[1] http://kerneltrap.org/node/3000
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Monday Ship Message, 2007-09-24

[Marco Pesenti Gritti]

On 9/24/07, Kim Quirk <[EMAIL PROTECTED]> wrote:
> The FRS schedule is right on the tail of this Trial-3 release. People who
> are not working on the few critical bugs left in trial-3, please start in on
> the bugs that have been moved into FRS. These fixes will need to be checked
> into a different stream (Jim, can you provide direction?). It is important
> that you have a place to check in and test; but these FRS fixes should NOT
> go into the next Trial-3 build.

For Sugar and activities we are creating trial-3 branches in git and
continue the 1.0 work on master.

Marco
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Monday Ship Message, 2007-09-24

[Kim Quirk]

   Ship update message for 2007-09-24

Schedule:
This week we are going to finalize the build for Trial-3. We are not putting
any more bug fixes in to the code base without approval from Jim or Kim. Jim
is reviewing all the bugs from the blocking status through high priority to
find the few that still need to be addressed. Kim is looking at all the
normal and low priority bugs with the intention of finding a good future
release for them. We are about a week behind where we want to be and we
expect to drop the first release of OFW (and OS) to Quanta (mfg) at the end
of this week.

The FRS schedule is right on the tail of this Trial-3 release. People who
are not working on the few critical bugs left in trial-3, please start in on
the bugs that have been moved into FRS. These fixes will need to be checked
into a different stream (Jim, can you provide direction?). It is important
that you have a place to check in and test; but these FRS fixes should NOT
go into the next Trial-3 build.

FRS code freeze is only 3 weeks from today.

Areas of Discussion this week:
Suspend/Resume updates
High priority Trial-3 bugs - journal (human readable names, backward
compatibility with v542), suspend/resume, activation and upgrades,
documenting or finding work-arounds for the rest
High priority small features for FRS
High priority/blocking bugs for FRS
Discussions on hiring (job descriptions available at the laptop.org website)

Meeting schedule:
Monday 1pm EDT, test meeting (call in line1)
Monday 3pm EDT, multi-battery charger update (call in line 1)
Tuesday noon EDT, Journal and Tubes update [trial-3 and frs bugs/features]
(call in line1)
Tuesday 3pm EDT, Content IRC chat (is this the correct time, SJ?)
Tuesday 4pm EDT, Security update [as well as a general update we should
discuss testing activation, bentham, laptop upgrades, rainbow] (no call in
yet)
Tuesday 9pm EDT, Bug review IRC chat (Jim will send out email if this
time/day changes; we have been discussing different times every week to give
people a chance to attend who can't otherwise)
Wednesday 10am EDT, UI/Sugar design meeting (ask Eben for call in info)
Wednesday 3pm EDT, School server update (no call in yet)

Call in line1: From the United States
866-213-2185
 From Outside the United States
1-609-454-9914
access code: 8069698
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Performance tuning for the XO

[Pádraig Brady]

C. Scott Ananian wrote:
> We make currently make heavy use of hashing in our upgrade &
> verification infrastructure.  I'd like to find the fastest possible
> implementation of the SHA-256 and/or RIPEMD-160 algorithms.  Can
> anyone offer me advice on the proper compilation options and
> strategies for maximum performance on the processor in the XO?  I
> don't see the -mxo option to gcc yet.
>  --scott

I've no hardware currently to test with unfortunately.
Some links that may be of interest though:

http://lists.laptop.org/pipermail/devel/2006-September/002415.html
http://dev.laptop.org/git?p=geode-perf;a=summary
http://www.lysator.liu.se/~nisse/nettle/
http://www.pixelbeat.org/scripts/gcccpuopt

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Vmware image

[Duncan Booth]

"Mike C. Fletcher" <[EMAIL PROTECTED]> wrote:

> You don't mention the host platform or the VMWare version you are 
> using.  I'm going to assume you are running on VMWare 5.x on Linux.  
> I've never managed to get USB devices working with any virtual machine 
> on my boxes, btw, and that didn't change just now when I went to map a 
> usb key drive into my vm.  Apparently people do it all the time, but it 
> doesn't work *here* anyway.  Anyway, reading around at:
> 
> http://forums.pcper.com/showthread.php?t=430890
> http://www.vmware.com/community/thread.jspa?threadID=94556&tstart=0
> 
> seems to suggest that various versions of vmware just don't support USB 
> 2.0 at all and suggest using e.g. a USB 1.1 hub in order to interface, 
> or to use "Player 2.0", which apparently does support USB 2.0.

VMWare 5.x does not support USB 2.0, VMWare 6.x/Player 2.0 will support USB 
2.0, but only if you are using a 'Workstation 6' image. The images at 
http://dev.laptop.org/pub/virtualbox/ are 'Workstation 5' images, so even 
if you use Player 2.0 you still won't get USB2 support.

If you have Workstation 6, then the fix is simple: you use the 'upgrade or 
change version...' command on the VM menu. I just tried that and it worked 
fine for me with Windows/XP as a host.

If you only have VMware player, then your best bet is probably to find 
someone who has Workstation 6 and ask them to convert the VM for you.

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel