SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I want to give an update. I find that after switching to kernel 2.6.23-rc1, the problem I have goes away. This is running Java 1.6 and TripleA. So CFS saves the day. Except this probably means that java has poor performance still.
Does this make other Java Apps work fast as well? As I said in my previous post the Java apps seem to work fine if you use them for a while. If the fix is in fact a kernel change I wonder what it could be.
Either way, it is much easier to install another version of Java than to use a different kernel. I would need a better reason to update my kernel than just this.
What has changed in the kernel is the new scheduler, CFS. I wouldn't say the new scheduler is a fix. It only makes the java apps more usuable. The real fix is to make java not suck.
For me, just using TripleA for a while won't necessarily fix the slowness. You may be lucky because maybe the increase in priority your app requires is all you need, and once it hits the right level, it works fine. You could have a faster CPU for this to happen.
Last edited by the3dfxdude; 07-31-2007 at 11:54 AM.
I was having sorta the same problem with jEdit (a text editor writen in java). I disabled a couple of things in the 2.6.21.5 kernel which came with slack12 and now java works fast just like before.
I could paste here the diff in the .config's but I dont know if this breaks something for someone else (It didnt break anything in my system). Just dont have to upgrade if you dont want to, just recompile the kernel.
As I said, maybe I disabled more than just the feature that was slowing java down but since I didnt do more extensive search to find it Im pasting all the diff. There are 2 options I disabled that had to do with the scheduler, maybe, as you said, that was the problem after all.
Probably a couple of settings dont have anything to do with the problem(for example reiserfs, math_emulation and intel dma).
Code:
root@sp:/usr/src/linux# diff config-original config-fixed
4c4
< # Tue Jun 19 14:44:11 2007
---
> # Tue Jul 31 04:29:42 2007
111,113c111,113
< CONFIG_TICK_ONESHOT=y
< CONFIG_NO_HZ=y
< CONFIG_HIGH_RES_TIMERS=y
---
> # CONFIG_TICK_ONESHOT is not set
> # CONFIG_NO_HZ is not set
> # CONFIG_HIGH_RES_TIMERS is not set
168,169c168,169
< CONFIG_SCHED_SMT=y
< CONFIG_SCHED_MC=y
---
> # CONFIG_SCHED_SMT is not set
> # CONFIG_SCHED_MC is not set
214c214
< # CONFIG_MATH_EMULATION is not set
---
> CONFIG_MATH_EMULATION=y
3281c3281
< CONFIG_INTEL_IOATDMA=m
---
> CONFIG_INTEL_IOATDMA=y
3312c3312
< CONFIG_REISERFS_FS=m
---
> CONFIG_REISERFS_FS=y
Yes its the smp kernel and im using an athlon xp 2600. So multithreading and multicore settings were kinda useless.
According to the CHANGES_AND_HINTS.TXT: "theoretically there should not be a performance penalty with using the SMP-capable kernel on a uniprocessor machine".
Since there arent many people reporting problems with java, maybe some settings in the default kernel are causing problems only in a few processors?
Currently I'm using a custom uniproc kernel. I doubt it's SMP that's the problem. SMT or MC might be interesting though, because they do play into the scheduler somehow. I wonder how CFS will affect those options too. But I guess for now, we just wait and see.
The first time I ran my java based chess app I noticed a slow down on my 3500+ fps ATI 9600 Slackware 12 / 2.6.21.5-smp 1.5 GB memory system... tried to change the JRE to 1.5 only to switch back to JRE 1.6 (using eclipse) and ran it again, this time it ran just fine with no extra cpu usage...
pay close attention to the cpu box under gkrellm. the first 1/2 of the graph is the results of the chess game on the left side of the screen. there the chess pieces move noticably slower and the cpu goes crazy. the chess game to the right side runs smoothly with no demands on the cpu... they are running the same Java JDK 1.6.0.2 (but not simulatenously)... no changes have been made other than the chess game on the right ran after the one on the left... what's going on slackware 12...?
I finally had some time to play around with this and I noticed some interesting things.
I installed JDK 1.4 and JRE 1.5. In addition, I removed the JRE 1.6 and installed the JDK 1.6 package from one of the Slackware mirrors.
Running my test software I noticed that there was NEVER a slow down using 1.4, but 1.5 had the same problem as JRE 1.6. However, after running the SAME software using 1.6 for a while I noticed that the CPU usage dropped dramatically and settled on a level even below what I believe 1.4 used. After reading up on the changes in Java I realized that the VM must be trying to optimize the code for my OS. One of the features of Java now is that it recompiles bits of the code as you use the software so that it can perform with native code speed. This is useful for applications that you run for a long time (ie. a server), but for running a new game for a couple of minutes it can be very frustrating.
It is important to note, however, that all of my test software was made using 1.4. Perhaps that is another factor.
Based on all of this I suggest that users install Java 1.4. You don't have to remove 1.6. If you don't want to type out the full path of 1.4 each time you use it I suggest you create a symbolic link in /usr/local/bin. That way when you want to run apps that you think will be slow just use java1.4 instead of java. Also, you can create links to the man pages and add them to your Manpath if you need this.
Note, however, that using the above method will not change your browser plugins, so if you want to use 1.4 as your main java do this instead: Change the symbolic link at /usr/lib/java to point to the 1.4 folder. Keep in mind that 1.4 does not have the same plugin name(*), so you will probably have to change the link in your plugins folder of your browser.
Since I mostly use java apps offline I decided to go with the first method. You might want to do the second one if you have been trying to use a lot of applets that are running slow with 1.6.
If anyone needs clarification on any of this let me know.
*Edit: it's not that the plugin has a different name but a different path (ns6*/ in 1.4 instead of ns7/)
I bet that's it. I just experienced the same thing. Moreover, I just had to reinstall my Slackware 12 due to a space requirement and the same thing happened with the Java. I have a chess app that does some basic animation. When I run it first it'll move it's pieces like something is holding it back. Then after a minute or two, it'll just take off to the same speed I was used to on my Slackware 10.1 platform.
Think you nailed it on the head. In any event, it works! Nice to see my ATI 9600 card being fully utilized!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.