LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (http://www.linuxquestions.org/questions/linux-general-1/)
-   -   What might i also need to recompile from changing major options in the kernel config (http://www.linuxquestions.org/questions/linux-general-1/what-might-i-also-need-to-recompile-from-changing-major-options-in-the-kernel-config-750126/)

sanitynotvanity 08-25-2009 10:25 AM

What might i also need to recompile from changing major options in the kernel config
 
Hi,

This is just a thought that I haven't had the time to exercise yet, so forgive me if its a little un-prepared.

I have a situation where by a c++ program of mine locks up after i have recompiled my kernel (only changed the processor option from a generic 486 to the specific processor) (that is the real processor, no mistake) VIA C7.

So i know that GCC needs to be compiled for the kernel and the kernel for the GCC (the chicken and the egg situation). This was all taken care off in the early days of building this operating system (LFS 6.4).

I know that if I am right to be thinking down these lines that there will be plenty of documentation around the issue - in fact too much documentation,

but I got lost

I don't need lengthy explanations, I am only asking if anyone knows of a particular link that I might need to spend my time reading.

Please let me know,

Andy

Tinkster 08-25-2009 12:43 PM

What an odd occurrence. I would have thought that the C7 has a
superset of the 486 instruction set (I haven't read up on this,
it's just the fact that the C7 is so much newer). Anyway:

I don't think you need to re-compile gcc ... all it should take
is to have your code recompiled.

Have you examined the part where your c++ program gets stuck
under gdb?


Cheers,
Tink

David1357 08-25-2009 12:44 PM

Quote:

Originally Posted by sanitynotvanity (Post 3656900)
So i know that GCC needs to be compiled for the kernel and the kernel for the GCC (the chicken and the egg situation).

You just need to make sure g++ uses the right "-march" option. This patch posted to LKML describes what the C7 kernel option actually does:
Re: [PATCH] Add an option for the VIA C7 which sets appropriate L1 cache
So, if build your program with "-march=i686" it should produce a binary that does not lock up.

Are you linking against any external libraries?

sanitynotvanity 08-25-2009 01:27 PM

Quote:

Originally Posted by Tinkster (Post 3657056)
What an odd occurrence. I would have thought that the C7 has a
superset of the 486 instruction set (I haven't read up on this,
it's just the fact that the C7 is so much newer). Anyway:

I don't think you need to re-compile gcc ... all it should take
is to have your code recompiled.

Have you examined the part where your c++ program gets stuck
under gdb?


Cheers,
Tink

Thanks for the response.

I can't use gdb due to the joys of using RTAI...

the program doesnt actually freeze sorry, but it does sit there consuming 100% cpu according to top. (and the system is VERY sluggish)

bizarre that i am actually getting the best real time results yet...

sanitynotvanity 08-25-2009 01:28 PM

Quote:

Originally Posted by David1357 (Post 3657057)
You just need to make sure g++ uses the right "-march" option. This patch posted to LKML describes what the C7 kernel option actually does:
Re: [PATCH] Add an option for the VIA C7 which sets appropriate L1 cache
So, if build your program with "-march=i686" and it should produce a binary that does not lock up.

Are you linking against any external libraries?

This sounds VERY promising

im stuck in unpaid over-time trying to get this going, this post has actually re-lifted my hopes!

ALSO, yes i am using 3rd party libraries. im linking with RTAI :S

David1357 08-25-2009 05:44 PM

Quote:

Originally Posted by sanitynotvanity (Post 3657109)
The program doesn't actually freeze sorry, but it does sit there consuming 100% cpu according to top. (and the system is VERY sluggish)

This is a completely different problem from a program "crashing" or "locking up". In fact, this may be completely normal behavior for your program. If your program is very CPU intensive, and never calls "sleep" or "sched_yield", this is exactly the behavior you would expect.

Also, I was very surprised that a kernel compiled with "-march=i686" would have problems running binaries compiled with "-march=i486". So, this set of symptoms makes more sense to me.

Quote:

Originally Posted by sanitynotvanity (Post 3657109)
bizarre that i am actually getting the best real time results yet...

Sounds like your kernel is fine and your program is fine. If you want your GUI to be more responsive, you will have to put in the occasional "sleep" or "sched_yield" into your program.

David1357 08-25-2009 05:48 PM

Quote:

Originally Posted by sanitynotvanity (Post 3657111)
im stuck in unpaid over-time trying to get this going, this post has actually re-lifted my hopes!

You should probably look at compiling your code with profiling enabled. This is a link to instructions for enabling profiling and using gprof.

sanitynotvanity 08-26-2009 02:32 AM

Quote:

Originally Posted by David1357 (Post 3657390)
This is a completely different problem from a program "crashing" or "locking up". In fact, this may be completely normal behavior for your program. If your program is very CPU intensive, and never calls "sleep" or "sched_yield", this is exactly the behavior you would expect.

Also, I was very surprised that a kernel compiled with "-march=i686" would have problems running binaries compiled with "-march=i486". So, this set of symptoms makes more sense to me.



Sounds like your kernel is fine and your program is fine. If you want your GUI to be more responsive, you will have to put in the occasional "sleep" or "sched_yield" into your program.

Let me start again,

I have a program that uses RTAI. Its written in C++ and its works fine when the kernel is complied for a 486 processor. its CPU usuage is between 20 and 40%.

After I have recompiled my kernel and changed the processor family from 486 to VIA C7 my program will then consume 100% of the processor.

sorry for not being more specific in my first post

David1357 08-26-2009 10:11 AM

Quote:

Originally Posted by sanitynotvanity (Post 3657830)
I have a program that uses RTAI. Its written in C++ and its works fine when the kernel is complied for a 486 processor. its CPU usuage is between 20 and 40%.

So what is throttling it from using 100% in this case? Is it doing some kind of hardware I/O that is slower when run against a kernel compiled with "-march=i486"? Is it waiting for user input? Is it reading or writing to a hard drive?

Quote:

Originally Posted by sanitynotvanity (Post 3657830)
After I have recompiled my kernel and changed the processor family from 486 to VIA C7 my program will then consume 100% of the processor.

Is there anything in your program that will throttle its performance (e.g. wait for user input, read from a file, wait for a digital I/O line to change state)? If there is nothing preventing your program from running as fast as it can, that is what it will do: run as fast as it can. This translates to 100% CPU usage.

Changing the kernel options so that it builds with "-march=i686" may have removed a throughput bottleneck that was preventing your program from running at maximum speed.

If you do not want your program to consume 100% of the CPU with the new kernel, you may have to put a "sleep" or "sched_yield" somewhere in one of your loops.


All times are GMT -5. The time now is 11:34 AM.