어플리케이션에서 말씀하시는건가요? 그렇다면, nice 명령어등으로 하시면, 효과는 있습니다. 해당 process가 실시간으로 꼭 어떤 작업을 처리해야 하는 경우가 아닌 상태에서 CPU가 90% 이상 차지하는 문제라면, 내부적으로 어느 정도 임의적으로 (u)sleep을 주는 방법 등이 있을 거 같습니다. 근데 어떠한 작업인지에 따라서 처리할 수 있는 방법이 또 달라질 수도 있는데, 혹시 말씀하실 수 있는건지요?

먼저 프로세스들의 역활을 간략하게 말씀하자면
세개의 A,B,C 프로세스가 있습니다.
A는 자바로 되어있고 네트웍을 통해(소켓) 데이터를 전송받으면 B에게 데이터를 전달합니다. (B는 C언어로 되어 있어 자바와 C언어의 프로세스 통신 방법을 생각하다가 printf,scanf를 사용하여 데이터를 전달합니다.) B에서 어떤 일을 한 다음에 다시 A로 데이터를 전송하고(소켓) A는 다시 C에게 데이터를 전송합니다.(역시 소켓)

데이터 흐름이 A -> B -> A -> C 이런식으로 흘러 가는데 중요한건 A가 CPU를 많이 차지해서 B가 적절한 타이밍에 데이터를 못가지고 가는 것이 문제입니다. (데이터 흐름이 아주 빈번하게 발생합니다.)

여기서 궁금한것이 2가지 있습니다.
하나는 자바와 C프로세스의 통신 방법이 소켓 외에 더 없을까 하는 것이고 (JNI는 안됩니다.)
두번째는 A가 CPU를 많이 차지 하는 이유가 혹시나 소켓통신을 해서 그런것이 아닌가 하는 것입니다. 구글링과 논문 검색으로 알아본바 소켓통신을 하게 되면 커널단에서 작업이 일어나는 것이라서(bottom half) 사용자 프로세스보다 우선순위가 높다는 것을 본것 같은데,, 혹시 그런 이유가 아닐까 해서요.

IPC에는 여러가지 방법이 있겠지만, 저라면 그냥 소켓으로 하겠습니다.

A 프로세스가 꼭 자바로 해야하는 것이 아니라면, only C로 하시는게 좋을것 같네요.

가볍게 만들어서 파이프나 리다이렉션을 이용해서 쉘 스크립트로 돌릴수도 있겠군요.

방법은 많으니 요구사항에 맞는 방법을 고려해 보세요

일단 현재 말씀하신 상황으로 보면 data path가 중요한 것으로 보이는데요. 즉 항상 A->B->A->C가 보장되어야 하는거 같습니다. 그렇다면, 일단, 이 data path를 보장해줘야 하는데, 중간에 printf, scanf를 사용해서 A->B로 데이터를 준다고 하셨는데, 어떻게 주시는지 이해가 잘 되지 않지만, 이 방식을 사용해서 A->B->A->C의 data path를 보장할 수 있는 건가요? 보장할 수 있다고 하더라도, 제 생각에는 A->B를 소켓을 사용해서 처리하면 좀더 수월하지 않을까 생각됩니다. 그리고 A만 90%를 사용한다고 하시는데, 이게 약간 이해가 되지는 않습니다. 소켓 통신이 non-blocking이 아닌 이상 A->C 통신으로 인해서 A가 적어도 한번의 data path에서 block 처리 될 터인데, 90%까지 올라간다는 것은 다른 이유로 인한 overhead이거나, 또는 정말 데이터의 양이 엄청나게 많다는 생각이 드네요. 후자라면, 이건 프로세스 우선순위뿐만 아니라, 좀더 많은 것을 고려하셔야 할 거 같습니다.

sys_sched_setscheduler 를 한번 알아보심이..
app 에 크게 문제가 없다고 생각되시면, scheduler 확인해보세요.
cfq 쓰시나요?

엇 cfq가 뭔가요???????????
완전 궁금해요.