deterministic usage of JIFFIES and how to relocate the clock

deterministic usage of JIFFIES and how to relocate the clock

[Joël Krähemann]

Hi all

Since I'm hardware newbie I just ask in my very own words, how to
relocate the clock. I want to play around with the clock modulator in
GNU/Linux. Is there any interface to relocate it?

What must do a user-space application do to change underlaying cipher?
I don't care about gdb or valgrind issues or trap-points. Might be in
further sense interrupts.

Is possible to have a VM in userspace? Once I have seen different VMs
available in the kernel. Does even have the VM control of
clock-modulator? Do I need some knowledge about ACPI to do so?

Are there some good books about that thematics I could start with?
Since I like math it would be fun to do so.

bests,
Joël Krähemann
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: deterministic usage of JIFFIES and how to relocate the clock

[Joël Krähemann]

Hi

At my opinion I was thinking at a lower level than needed. The
application runs at least aside the kernel.
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.

int sched_setaffinity(pid_t pid, size_t cpusetsize,
                             const cpu_set_t *mask);

void longjmp(jmp_buf env, int val);

cheers,
Joël


On Fri, Jan 22, 2016 at 10:37 AM, Joël Krähemann <jkraehemann@gmail.com> wrote:
> Hi all
>
> Since I'm hardware newbie I just ask in my very own words, how to
> relocate the clock. I want to play around with the clock modulator in
> GNU/Linux. Is there any interface to relocate it?
>
> What must do a user-space application do to change underlaying cipher?
> I don't care about gdb or valgrind issues or trap-points. Might be in
> further sense interrupts.
>
> Is possible to have a VM in userspace? Once I have seen different VMs
> available in the kernel. Does even have the VM control of
> clock-modulator? Do I need some knowledge about ACPI to do so?
>
> Are there some good books about that thematics I could start with?
> Since I like math it would be fun to do so.
>
> bests,
> Joël Krähemann
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: deterministic usage of JIFFIES and how to relocate the clock

[Sebastian Andrzej Siewior]

* 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: deterministic usage of JIFFIES and how to relocate the clock

[Joël Krähemann]

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@linutronix.de> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html