gnome is very slow

[jjstorm]

Originally Posted by jggimi

Only if the working directory receives changes from the repository.

Consider the value of cvs -q. If you use $ cvs -q up -Pd, you will more clearly see any changes applied.

If the working directory has received changes, the steps to follow are in 5.2.4 and 5.2.5 of the faq? I want to be clear on that, because that is what I have been doing.

I have been following the patch branch.

For example:

I initially downloaded the source tree with this command:

# cd /usr
# cvs -qd anoncvs@anoncvs.ca.openbsd.org:/cvs get -rOPENBSD_5_8 -P src

Then I recompiled the kernel and the user land as outline in sections 5.2.4 and 5.2.5 of the faq, rebooting the system after the kernel was compiled, and then after the user land was compiled. When I reboot after the kernel, The system shows that I am running -stable.

After, when patches have come out, I have updated the source tree, by navigating to the working directory and just using the command to update:

# cd /usr/src
# cvs -q up -rOPENBSD_5_8 -Pd

Then I would recompile the kernel and the user land again as outlined in sections 5.2.4 and 5.2.5.

Isn't the above the correct procedures for following the patch branch?

[e1-531g]

There was also glxinfo command, but neverthless glxgears suggests that acceleration for OpenGL programs is working, at least if OpenGL program uses GLX. As I said - Gnome on Gnu/Linux use EGL. Probably Gnome on OpenBSD also uses EGL.
Neverthless.
I would suggest to put something like that in sysctl.conf

$ grep aperture /etc/sysctl.conf                                               
machdep.allowaperture=2         # See xf86(4)

You can get example of sysctl.conf from /etc/examples/sysctl.conf.
Reboot.

[jggimi]

Originally Posted by jjstorm

If the working directory has received changes, the steps to follow are in 5.2.4 and 5.2.5 of the faq?

I want to be clear on that, because that is what I have been doing.

Yes, but. Your goal is -stable. The FAQ is more broad, and covers -current, as well as providing guidance for those who maintain using errata patches, such as its instructions on building and installing a kernel.

Let's review: what is -stable? It is security and stability fixes for a -release, that includes published errata and may also include additional commits. Those committed patches are different than development patches, because they never alter a) interfaces or b) libraries. There are some considerations of this limitation that are not explicitly articulated in the FAQ.

One example: as there are no interface alterations, there is no specific benefit to rebooting immediately after building a -stable kernel. True, a -stable kernel commit may solve a problem or mitigate a risk, but as there are no interface changes, there is no functional change to the kernel necessitating a reboot before continuing with a userland build.

After, when patches have come out, I have updated the source tree, by navigating to the working directory and just using the command to update:

# cd /usr/src
# cvs -q up -rOPENBSD_5_8 -Pd

Then I would recompile the kernel and the user land again as outlined in sections 5.2.4 and 5.2.5.

That's fine. But:

• The -r tag is "sticky" so it isn't required.
• There is no harm in rebuilding everything, but if you read through the cvs output, you will see some commits will update the kernel source (sys/...) and others will update userland. If there were no changes to the kernel, it isn't strictly necessary to rebuild.

I build -stable releases and -stable packages, because I maintain multiple -stable servers. I'm OK with the wall-clock time, because the builds are scripted and require little attention. I also build -stable systems because I have been building them since before the founding of M:Tier. Had they predated me, I would likely use them.

And because updates to -stable which are not published as errata are only published to the CVS repositories (and commit log mailing lists), cvs updates are part of my daily(8) local scripts.

Originally Posted by e1-531g

I would suggest to put something like that in sysctl.conf

$ grep aperture /etc/sysctl.conf                                               
machdep.allowaperture=2         # See xf86(4)

You can get example of sysctl.conf from /etc/examples/sysctl.conf.
Reboot.

The drm(4) video drivers inteldrm(4) and radeondrm(4) do not use the xf86() aperture driver. This knob is not needed.

[jjstorm]

Originally Posted by jggimi

• The -r tag is "sticky" so it isn't required.
• There is no harm in rebuilding everything, but if you read through the cvs output, you will see some commits will update the kernel source (sys/...) and others will update userland. If there were no changes to the kernel, it isn't strictly necessary to rebuild.

How do I read the cvs output? I think you may have mentioned this before.

Why is it that if there are changes to the userland, it is not necessary to rebuild?

[jggimi]

Originally Posted by jjstorm

..I will try to fix this as soon as possible and report back.

Did you ever solve your performance problem? Remember, post #1 way up top? I think it was only a day or so ago.

Originally Posted by jjstorm

How do I read the cvs output? I think you may have mentioned this before.

The cvs(1) update output reports changes it makes to files in the working directory. "P <file>" applies a patch, "U <file>" replaces the file completely.

CVS will also inform you with one character status values when it finds a local modification with "M", a conflict with "C", a local file that is not in the repository with "?". The complete list of these can be found in the cvs(1) man page.

The program will also inform you when a file is deleted, but much less cryptically, with "<file> is no longer in the repository." You will see this when you transition from 5.8-stable source to 5.9-stable source. At that time, all you'll need to do is an update with the OPENBSD_5_9 tag.

Why is it that if there are changes to the userland, it is not necessary to rebuild?

I must not have been clear. If you ask the question differently, such as "Why if there are no changes to the kernel, is it not necessary to rebuild the kernel?" then the question answers itself.

An OS kernel is the central program that operates the hardware and provides all programs with access to services, such as compute time and input/output. On OpenBSD, its the program that produces white text on blue background on architectures with color consoles.

All of the other programs and utilities included with an OS are not part of the kernel. For OpenBSD, we name these "userland" because they run in user address space, not in the kernel's address space. We add a further class of programs, which are not built-in: packages. These are programs which are not part of OpenBSD per se, mainly from other open source projects, and the packages we install are built from the ports tree, which is merely a collection of build instructions and packaging information.

[jjstorm]

After reinstalling the entire system, and now running GENERIC.MP , I can report a massive performance improvement in Gnome. Web pages render quickly. Gnome is now very responsive to queries. Video no longer skips.

Not only is Gnome more responsive, but the entire system in general seems to be much quicker. Compiling the userland went much faster than it had previously.

Sorry it took so long to respond, I had some difficulty getting gnome installed, but I was able to accomplish it.

[jggimi]