{21} Detailed changes to bugs tagged 8.2.0 (10524 matches)

Pull out details of the recent changes to release-critical bugs for convenient release management.

Results (1 - 100 of 10524)

1 2 3 4 5 6 7 8 9 10 11

#118: GCC optimizations (43 matches)

Ticket Author Date Created Field Description
#118 blizzard Oct 2, 2006 5:31:06 PM comment

Jim, do you have the code that has the perf optimizations for the Geode that was mentioned in Weekend?

#118 blizzard Oct 2, 2006 5:31:06 PM status

assigned

#118 jg Oct 2, 2006 10:21:47 PM comment

Replying to blizzard:

Jim, do you have the code that has the perf optimizations for the Geode that was mentioned in Weekend?

They are in git, of course.

See the geode-perf project in Git.

http://dev.laptop.org/git?p=geode-perf;a=summary

but this is orthogonal to improvements in gcc; this is about improvements in glibc and other places....

#118 jg Mar 24, 2007 3:17:29 PM comment

We should remember to ensure the GCC folks, both in RH and elsewhere, know we are moving to LX. It does have some significant differences.

#118 jg Mar 24, 2007 3:17:29 PM milestone

CTest

#118 jg May 17, 2007 11:04:08 AM owner

bernie

#118 jg May 17, 2007 11:04:08 AM status

new

#118 jg May 17, 2007 11:04:08 AM verified

0

#118 bernie May 21, 2007 11:24:00 AM comment

I've talked it over with Rob Savoye. He made the olpc toolchain based on gcc 4.3 and integrated AMD's string operations in glibc. I will leverage his work and push it upstream.

Meanwhile, I'm asking the GCC maintainers when they plan to release 4.3 because it already contains several performance improvements that we'd probably like to have.

The current svn trunk is in a good shape, but they may soon start merging a long queue of pending projects that will likely disrupt stability. I'm begging them to postpone this work to 4.4 and branch 4.3 now.

#118 bernie May 23, 2007 4:24:16 PM status

assigned

#118 bernie Jul 13, 2007 12:45:41 AM comment

We have the geode optimizations in the gcc-4.1 shipped with F7, but we're not turning on -march=geode on any builds we make.

I'd like to ask some Fedora developer if we can add geode to the list of archs supported in Makefile.common.

This would make it easy for us to build all our custom rpms for the geode. python, glibc, cairo and xorg are pretty performance critical.

#118 bernie Sep 4, 2007 6:11:23 PM comment

I got a Fedora developer to add "geode" in Makefile.common. I've not yet figured out how to ask koji to build an RPM for geode, though.

My local builds of glibc for the geode make applications crash istantaneously. glibc problems are hard to debug and I had no time to investigate further.

It could be an issue with my build enviroment (environment variables creeping in, etc). This is why I wanted to build in Koji.

#118 jg Sep 16, 2007 8:52:22 PM milestone

V1.1

#118 cscott Sep 22, 2007 1:55:58 PM comment

If/when we set up our own build environment, we could consider building all our packages with geode optimizations turned on.

#118 cscott Sep 22, 2007 1:55:58 PM cc

cscott

#118 bernie Sep 22, 2007 6:18:27 PM comment

I would recommend that too.

I have a full koji server setup running on my desktop, with some outstanding problems. Koji is quite complicated and takes a lot of time to install, so we may want to start from there and maybe move it to a proper server later.

#118 bmcarnes Oct 29, 2007 6:56:29 PM comment

Are the glibc problems with geode optimizations still present?

I'm volunteering to build some or all of the XO software with -march=geode and debug any issues that arise.

It sounds like gcc 4.1 geode optimizations are a good start; if we get them working in this project, we can see where the gcc 4.3 release (w/ better geode tuning) is, and discuss how to leverage those changes for the XO.

Let me know how I can help.

#118 bernie Nov 1, 2007 5:06:18 AM cc

cscott, rsavoye

#118 bernie Nov 1, 2007 5:06:18 AM comment

Replying to bmcarnes:

Are the glibc problems with geode optimizations still present?

Rob Savoye gave us a new version of the patches with a problem fixed:

http://wiki.gnashdev.org/wiki/index.php/Building_OLPC_Tools

So far I couldn't find the time to re-apply the patches to the glibc rpm we use in joyride.

I'm volunteering to build some or all of the XO software with -march=geode and debug any issues that arise.

Cool! But this has to be done in rpm, and possibly using Koji.

I do that by putting "%optflags -O2 -march=geode" in my ~/.rpmmacros, but eventually it has to be done on the specific packages we want to rebuild for geode.

For now, rebuilding everything with -march=geode is not an option, or we loose the ability to use prebuilt packages from upstream. With some collaboration from the Fedora engineers, maybe we can add geode as a new i386 variant besides i686 and athlon.

It sounds like gcc 4.1 geode optimizations are a good start; if we get them working in this project, we can see where the gcc 4.3 release (w/ better geode tuning) is, and discuss how to leverage those changes for the XO.

I'm afraid we can't use gcc 4.3 as our default compiler until we update to a new version of Fedora that includes it by default. The reason is that too many packages may need fixing to compile cleanly and we lack engineering resources to fix them all.

But we could certainly add a gcc43 package containing /usr/bin/gcc43 and build specific packages against it.

Let me know how I can help.

An interesting project would be providing a few benchmarks showing how much these optimizations could benefit us in interesting test cases.

Then, working closely with our upstream would be best so we can benefit indirectly. Again, we'd all be reluctant to diverge too much for small gains, because we lack engineering resources to maintain hundreds of packages.

#118 rsavoye Nov 1, 2007 5:32:00 PM comment

Replying to bernie:

I do that by putting "%optflags -O2 -march=geode" in my ~/.rpmmacros, but eventually it has to be done on the specific packages we want to rebuild for geode.

I'm not 100% sure how you do your builds, but for most packages, setting CC to "gcc -march=geode -mtune=geode" works fine.

For now, rebuilding everything with -march=geode is not an option, or we loose the ability to use prebuilt packages from upstream. With some collaboration from the Fedora engineers, maybe we can add geode as a new i386 variant besides i686 and athlon.

Using -march=geode would only effect the packages built with this compiler. There shouldn't be any problem mixing these executables with prebuilt upstream packages.

It sounds like gcc 4.1 geode optimizations are a good start; if we get them working in this project, we can see where the gcc 4.3 release (w/ better geode tuning) is, and discuss how to leverage those changes for the XO.

The geode optimizations for GCC are a minor tweak to the existing pentium support. It would be entirely possible to migrate the GCC patch to GCC 4.1.x. I've found a multitude of bugs in Gcc 4.1.2, but I think applying this patch to gcc 4.2l.1 makes sense, and it's a better compiler in general than 4.1.x. So maybe adding a hacked 4.2.1 is better than GCC 4.3, as 4.3 isn't released yet, it's basically just a SVN snapshot.

An interesting project would be providing a few benchmarks showing how much these optimizations could benefit us in interesting test cases.

When I get back from this conference, that's my plan. The geode-perf tests this work is based on aren't setup this way, but my plan was compile some standard benchmarks with the unmodified GCC/GLIBC, and then again with the modified version to see if there are any real world improvements. Testing the GLIBC tweaks in isolation has shown a 20% improvement in performance, but the real test is how this effects regular applications.

Then, working closely with our upstream would be best so we can benefit indirectly. Again, we'd all be reluctant to diverge too much for small gains, because we lack engineering resources to maintain hundreds of packages.

If the GLIBC improvements do offer some improvement by itself, then any application dynamically linked against GLIBC would use the better performing version when installed on an X0.

#118 bmcarnes Nov 1, 2007 9:20:22 PM cc

cscott, rsavoye, bmcarnes

#118 bmcarnes Nov 1, 2007 9:20:22 PM comment

I agree w/ Rob that we can and should rebuild certain key packages (glibc, perhaps even python and other main interpreters) with geode optimization.

They should mix and match fine, and shouldering the burden of building a few packages might be worth it; the rest can certainly come prebuilt from upstream until there is a Geode-targeting Koji build server.

When does Rob return from conference? What should I do in parallel that'll help but not duplicate his effort?

Shall I try building us a gcc 4.2.2 compiler with the geode patches from 4.3?

From what I can see of the geode-gcc-4.2.patch on gnashdev.org, it does not do anything for the two new geode-specific 3dnow instructions, which include the very useful inverse sqrt. Shall I take a look to see if it's in gcc 4.3 at all, and try my hand at pulling it into the patch, or adding a peephole optimization for it if it isn't supported in gcc yet?

#118 AlbertCahalan Nov 2, 2007 12:20:27 AM comment

Replying to bmcarnes:

From what I can see of the geode-gcc-4.2.patch on gnashdev.org, it does not do anything for the two new geode-specific 3dnow instructions, which include the very useful inverse sqrt. Shall I take a look to see if it's in gcc 4.3 at all, and try my hand at pulling it into the patch, or adding a peephole optimization for it if it isn't supported in gcc yet?

Note that the Geode also includes partial support for SSE1 and SSE2. Being partial, you can't just enable gcc's code generation for those features.

http://wiki.laptop.org/go/Geode_instruction_set

#118 rsavoye Nov 2, 2007 1:16:57 PM comment

Replying to AlbertCahalan:

From what I can see of the geode-gcc-4.2.patch on gnashdev.org, it does not do anything for the two new geode-specific 3dnow instructions, which include the very useful inverse sqrt. Shall I take a look to see if it's in gcc 4.3 at all, and try my hand at pulling it into the patch, or adding a peephole optimization for it if it isn't supported in gcc yet?

The patch was originally developed for the Geode GX, so yes, it would be a good idea to add this instruction as I believe it'll help performance on the LX.

#118 bernie Nov 5, 2007 11:25:53 AM comment

Does anybody have time to rebase glibc patches on glibc-2.7 from F8? This is the version we need to ship for localization.

The latest RPM by Rob is here:

http://www.gnashdev.org/olpc/glibc-2.6-5.olpc.src.rpm

#118 rsavoye Nov 5, 2007 11:29:37 AM comment

Replying to bernie:

Does anybody have time to rebase glibc patches on glibc-2.7 from F8? This is the version we need to ship for localization.

This would actually be very easy. Other than a hack to Makeconfig for using GCC 4.3 (-march instead of -mcpu), all the changes are in a single subdirectory, that merely has to be copied to the correct location. (sysdeps/i386/i686/geode) Glib's configure code is weird, but auto-senses the correct cpu variant when you configure with the --with-cpu=geode option.

#118 bernie Nov 28, 2007 12:15:13 PM comment

Initial porting to glibc 2.7:

http://www.codewiz.org/pub/glibc-geode-2.7/

#118 bernie Dec 11, 2007 10:00:33 PM comment

Seems to work well.

Dgilmore tought yum about the geode. We're now waiting for a geode enabled RPM to move this package in.

#118 mstone Jun 5, 2008 8:23:17 PM owner

dgilmore

#118 mstone Jun 5, 2008 8:23:17 PM priority

normal

#118 mstone Jun 5, 2008 8:23:17 PM cc

cscott, rsavoye, bmcarnes, mstone, jg, dgilmore, bernie

#118 mstone Jun 5, 2008 8:23:17 PM status

new

#118 mstone Jun 5, 2008 8:23:17 PM milestone

Update.2 (8.2.0)

#118 mstone Jun 5, 2008 8:23:17 PM keywords

rel-8.2.0:?

#118 mstone Jun 5, 2008 8:23:17 PM comment

Any progress here?

#118 andresambrois Sep 26, 2008 11:24:17 PM comment

I second the ping above. This looks like an interesting optimization now that gcc-4.3 is being used.

Are the geode-specific optimizations being used in the builds?

#118 andresambrois Sep 26, 2008 11:24:17 PM next_action

never set

#118 andresambrois Sep 26, 2008 11:24:17 PM cc

cscott, rsavoye, bmcarnes, mstone, jg, dgilmore, bernie, andresambrois

#118 cscott Sep 28, 2008 10:43:49 AM milestone

9.1.0

#118 cscott Sep 28, 2008 10:43:49 AM comment

Dennis, is this one of the compelling benefits we could obtain by moving to your mash-based system, rebuilding every package in fedora against the olpc3 root? Is there a build root configuration we could do to apply these optimizations by default in 9.1/olpc4/F10?

#118 dgilmore Sep 28, 2008 11:12:53 AM comment

things like glibc and openssl probably definitely should be optimised for geode. we could make the normal fedora build do those optimisations. and using mash we can make sure that we provide the .gedoe rpms. one area that will need to be fixed for this to work correctly is the tools that create the images. they need to learn that we build for geode and they install geode rpms. right now they install i686 glibc and openssl.

#118 cscott Sep 28, 2008 12:31:05 PM comment

Can we start by creating some geode rpms in koji? Then I can futz with pilgrim's configuration and make sure it will pull them.

#118 dgilmore Sep 28, 2008 1:23:34 PM comment

yep :) glibc and openssl seem like obvious ones to start with. what other ones do we think we might need?

#137: Performance work on key functions. (4 matches)

Ticket Author Date Created Field Description
#137 mstone Jun 5, 2008 8:24:24 PM milestone

Update.2 (8.2.0)

#137 mstone Jun 5, 2008 8:24:24 PM cc

bernie, cscott, mstone, dgilmore, tomeu

#137 mstone Jun 5, 2008 8:24:24 PM keywords

rel-8.2.0:?

#137 mstone Jun 5, 2008 8:24:24 PM verified

0

#317: X authority file should be in tmpfs not jffs2 (53 matches)

Ticket Author Date Created Field Description
#317 jg Nov 15, 2006 4:08:28 PM comment

I'm not sure this matters: we don't log in often anyway.

#317 jg Nov 15, 2006 4:08:28 PM priority

low

#317 jg Nov 15, 2006 4:08:28 PM milestone

BTest-2

#317 jg Dec 26, 2006 6:34:12 PM status

closed

#317 jg Dec 26, 2006 6:34:12 PM resolution

wontfix

#317 jg Dec 26, 2006 6:34:12 PM comment

I agree (unless X is crashing).

I'm going to close this.

#317 wmb@firmworks.com Aug 3, 2007 9:45:01 PM verified

0

#317 wmb@firmworks.com Aug 3, 2007 9:45:01 PM comment

A recent analysis of the NAND FLASH image from a lightly-used system makes me think that this is a problem worth fixing. The system in question has been reinstalled from scratch and then used only briefly. It had 33 new dirents for either ".Xauthority", ".Xauthority-c", ".Xauthority-l", and ".Xauthority-n", all in /home/olpc. It had 15 dirents for /root/.xauthXXXXXX{,-c,-l,-n}, and 19 for /home/olpc/.serverauth.NNNN{,-c,-l,-n}.

All told, that is 77 pointless scribbles to NAND.

#317 wmb@firmworks.com Aug 3, 2007 9:45:01 PM status

reopened

#317 jg Aug 6, 2007 4:19:32 PM milestone

Trial-3

#317 jg Aug 6, 2007 4:19:32 PM owner

J5

#317 jg Aug 6, 2007 4:19:32 PM comment

The problem is that both clients and servers have to agree on this location. A symbolic link in /home/olpc is probably the right solution. But I don't know if anything might remove the link or not, or just rewrite the file.

#317 jg Aug 6, 2007 4:19:32 PM priority

normal

#317 jg Aug 6, 2007 4:19:32 PM status

new

#317 J5 Aug 6, 2007 6:06:21 PM comment

So the big problem here is that it doesn't put the file in a directory by itself and the file name is variable so I can't just add it to /etc/rwtab. I think the only sane thing is to make X place the file in a directory I can add to tmpfs

#317 J5 Aug 20, 2007 4:08:23 PM comment

ok, I must be on crack when I wrote the above /home/olpc/.Xauthority is constent so it as easy as adding it to /etc/rwtab in initscripts.

#317 J5 Aug 20, 2007 9:44:44 PM comment

hmm, ok so .serverauth.$number is the one I was thinking about before. That one is a little more tricky

#317 kimquirk Sep 24, 2007 10:50:58 PM milestone

First Deployment, V1.0

#317 Quozl Oct 25, 2007 5:45:15 PM comment

Build 619, problem continues to occur.

A /home/olpc/.serverauth.$$ is created for every start of X, and removed only if xinit returns, which with Sugar never happens.

The /home/olpc/.Xauthority is intentionally unlinked by xauth so that it can create a new one if the host name changes, but this unlink fails with EBUSY due to the entry in /etc/rwtab.

We need a different place to put these temporary files in the context of the olpc user ... we can use XAUTHORITY environment variable for that. I'll look for where to put them.

#317 Quozl Oct 25, 2007 5:45:15 PM status

assigned

#317 Quozl Oct 25, 2007 5:45:15 PM owner

Quozl

#317 Quozl Oct 25, 2007 6:56:17 PM comment

Editing /etc/rwtab to remove /home/olpc/.Xauthority, and editing /usr/bin/startx to use /var/tmp instead of $HOME for both authority files works fine, in that Sugar starts okay, the XAUTHORITY environment variable is inherited by anything that Sugar starts.

The strace of xauth shows that the file is created with mask 0600.

But anything not started from Sugar, such as inbound SSH sessions, needs to be told where the authority file has got to. This could be solved with a symlink in /home/olpc.

An alternate method of adding XAUTHORITY in olpc-dm using setenv(3) was also explored, but this doesn't let us change where the server authority file is stored.

#317 jg Oct 25, 2007 10:37:23 PM comment

does olpc-dm invoke startx?

I'm also worried about potential security attacks...

Michael?

#317 jg Oct 25, 2007 10:37:23 PM cc

mstone

#317 jg Oct 25, 2007 10:37:23 PM priority

high

#317 Quozl Oct 25, 2007 11:16:13 PM comment

Yes, olpc-dm invokes startx. Rather than package-fork startx, I've proposed adding our version olpc-startx to olpc-utils.

#317 Quozl Oct 25, 2007 11:46:23 PM status

new

#317 Quozl Oct 25, 2007 11:46:23 PM comment

Agreed, please review security impact.

Note: two patches needed, attached. Don't know how to build an RPM myself from my repository though.

Reassigning to Bernie on his request.

#317 Quozl Oct 25, 2007 11:46:23 PM cc

mstone, quozl

#317 Quozl Oct 25, 2007 11:46:23 PM owner

bernie

#317 bernie Nov 1, 2007 12:47:58 AM resolution

wontfix

#317 bernie Nov 1, 2007 12:47:58 AM keywords

killjoy?

#317 bernie Nov 1, 2007 12:47:58 AM status

closed

#317 bernie Nov 1, 2007 12:47:58 AM comment

So we discussed with dwmw2 and m_stone and we're all convinced .Xauthority is fine where it is:

  • /home/olpc/ is supposed to be a writable directory, even if the root were mounted read-only
  • We're writing to it only *once* per boot, so flash wearing and performance aren't clearly a concern

The only change we really need is *not* bind mounting it, as is already the case in joyride. It should be done in killjoy too, maybe.

#317 cscott Jul 22, 2008 3:49:42 PM comment

Reopened: this causes sugar to fail to boot in low disk situations.

#317 cscott Jul 22, 2008 3:49:42 PM status

reopened

#317 cscott Jul 22, 2008 3:49:42 PM next_action

never set

#317 cscott Jul 22, 2008 3:51:03 PM status

new

#317 cscott Jul 22, 2008 3:51:03 PM owner

cscott

#317 cscott Jul 22, 2008 3:51:03 PM comment

Replying to Quozl:

Editing /etc/rwtab to remove /home/olpc/.Xauthority, and editing /usr/bin/startx to use /var/tmp instead of $HOME for both authority files works fine, in that Sugar starts okay, the XAUTHORITY environment variable is inherited by anything that Sugar starts.

The strace of xauth shows that the file is created with mask 0600.

But anything not started from Sugar, such as inbound SSH sessions, needs to be told where the authority file has got to. This could be solved with a symlink in /home/olpc.

I like this solution.

#317 cscott Jul 23, 2008 2:16:49 PM comment

Got some patches to initscripts & pilgrim, testing them now.

#317 cscott Jul 24, 2008 12:03:43 PM comment

Rainbox patch is at http://dev.laptop.org/git?p=users/cscott/security-tmp;a=commitdiff;h=002b4f43641977cbdf2b60a0d09d1607d093ec16 ; see also http://dev.laptop.org/git?p=users/cscott/security-tmp;a=commitdiff;h=282132d40aa368769415ca6fff2d5e2c28110d98 for unrelated fixed to the Makefiles to make cross-building from debian possible.

#317 cscott Jul 24, 2008 12:08:10 PM cc

mstone, quozl, cjb

#317 cscott Jul 24, 2008 12:08:10 PM comment

With revised initscripts (for #7586), olpc-utils (for revised olpc-dm), and rainbow patch mentioned above, sugar starts fine with Xauthority and ICEauthority moved to /var/tmp.

*However*, ohm's xorg plugin is currently having issues, as the spec file we are using hard-codes OHM_DEVICE_XAUTH_DIR to /home/olpc (see http://dev.laptop.org/git?p=projects/ohm;a=blob;f=plugins/glue/xorg/ohm-plugin-xorg.c;h=3bca47be8764531cba2bbd157d1e3bdc4defea41;hb=HEAD#l42 ).

I can either make a compatibility symlink from /home/olpc to /var/tmp/.Xauthority-olpc, or else patch ohmd to set OHM_DEVICE_XAUTH_DIR to /var/tmp (and remove the $LOGNAME suffix from the filenames, or else set OHM_DEVICE_XAUTH_DIR to /var/tmp/olpc-auth and have olpc-dm create this directory if necessary... anyone have preferences?

#317 cscott Jul 24, 2008 1:18:26 PM comment

Fix landed for #7586 in initscripts, and patch for startx landed in pilgrim.

Waiting on synchronized landing of olpc-utils, rainbow, and ohm.

#317 cscott Jul 24, 2008 1:51:24 PM comment

m_stone: http://dev.laptop.org/git?p=users/cscott/olpc-utils-tmp;a=commitdiff;h=725f8cea2c01a523c55d863029f000225763fa4c and http://dev.laptop.org/git?p=users/cscott/security-tmp, if you please. Please coordinate with cjb so he can land his ohm specfile change into olpc-3 at the same time.

#317 cscott Jul 24, 2008 1:51:54 PM next_action

package

#317 cscott Jul 24, 2008 1:51:54 PM owner

mstone

#317 cscott Jul 24, 2008 2:26:01 PM comment

Ergh, please use http://dev.laptop.org/git?p=users/cscott/olpc-utils-tmp;a=commitdiff;h=f83aadc7252152cc6c51a143815aaf0435e55fe3 instead.

#317 cscott Jul 25, 2008 12:38:33 AM next_action

test in build

#317 cscott Jul 25, 2008 12:38:33 AM comment

In joyride-2208 (ohm 0.1.1-6.15.20080707git.olpc3, rainbow 0.7.16-1.fc9, and olpc-utils 0.81-1.olpc3). To test:

  • Open up the Terminal activity.
  • Type: "ls -a /var/tmp/olpc-auth". You should see .Xauthority, .ICEauthority, and .Xserverauth files.
  • Type: "echo $XAUTHORITY $ICEAUTHORITY $XSERVERAUTH". The locations of these files in /var/tmp should be reported.
  • Open up the Pippy activity. Type in the following short program, and press "Go":
    import os
    os.system('/bin/bash')
    
  • At the resulting shell prompt, repeat the above echo command. You should see locations for XAUTHORITY and friends which are in /home/olpc/isolation/<mumble>.
  • Type xdpyinfo. You should get some output (ie, xdpyinfo should be able to use the XAUTHORITY setting to connect to the X server.)
  • Close pippy.
  • In the Terminal application, type: "cat /dev/urandom > /home/olpc/space-filler" This may take quite a while, but will eventually report "no space available". Congratulations, your NAND is full!
  • Reboot. X should start up and you should see the sugar home screen (beyond X startup, we've entered the territory of trac #7587).
#317 cscott Jul 25, 2008 12:38:33 AM blocking

7125, 7587

#317 mtd Aug 4, 2008 6:44:21 PM cc

mstone, quozl, cjb, mtd

1 2 3 4 5 6 7 8 9 10 11
Note: See TracReports for help on using and creating reports.