Hi At my opinion I could do some optimization by controlling what gets into the stack and at what time in program lifetime. I'm doing a realtime sequencer in C. http://gsequencer.org Basically it does a lot of additions to calculate the audio data to output to soundcard. I have a thread object that does 1000 cycles per second. That's why I'm talking about JIFFIES not related to the kernel ones. Deterministic in this view of doing the job in time say within the range of a mili-second. At bigger loads it takes may be 5 to 8 mili seconds to do additive mixing. What I want to do is to bypass the bottle-neck. Further I believe there's much time wasted by loading or unloading a thread into CPU. There might be at least 1 audio thread and 2 channel threads with a simple setup but generally depends on how many sound sequencers you have. For a basic band with 5 instruments there are 15 threads, one gui thread, a main loop and a thread pool serving non blocking functions. So you get quickly more than 20 threads. The problem is doing additive sound mixing and at my opinion how the program gets loaded/unloaded into the stack. It eats much computing time. So is there an API to solve this issue to control the stack? So far I have found pthread_yield() but I'm not happy with it. Bests, Joël On Thu, Feb 4, 2016 at 5:44 PM, Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > * Joël Krähemann | 2016-01-24 09:40:33 [+0100]: > >>Hi > Hi, > >>At my opinion I was thinking at a lower level than needed. The > I couldn't parse the question in the previous mail. > >>application runs at least aside the kernel. > > aside the kernel? Like one CPU is for the kernel and the other for the > application? > >>Probably I want to control PC (program counter) and redeclare the >>longjump function as macro. To gain control >>over throughput rate and thus being able to grain loading and unloading thread. > > maybe. But I still fail to understand what you attempt to do. > >>int sched_setaffinity(pid_t pid, size_t cpusetsize, >> const cpu_set_t *mask); > > This one says which CPUs the task may run on. > >>void longjmp(jmp_buf env, int val); > > and this is unrelated to the previous one. > >> >>cheers, >>Joël > > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
