Jonathan Andrews jonshouse.co.uk> writes:
>
> What about a yield alignment mechanism for user space. IE the process
> calls the kernel with a request "schedule me first after a yeild" - then
> the process at least has whatever the timer granularity is to do
> something timing critical... add a
Jonathan Andrews jon at jonshouse.co.uk writes:
What about a yield alignment mechanism for user space. IE the process
calls the kernel with a request schedule me first after a yeild - then
the process at least has whatever the timer granularity is to do
something timing critical... add a
On Sun, 2013-02-17 at 18:05 -0800, Greg KH wrote:
> On Sun, Feb 17, 2013 at 02:37:24PM +, Jonathan Andrews wrote:
> > From a user perspective it seems a bit crap to have to change the kernel
> > if you have a workload that preemption is harmful to.
> > In the case of something like the
On Sun, Feb 17, 2013 at 02:37:24PM +, Jonathan Andrews wrote:
> From a user perspective it seems a bit crap to have to change the kernel
> if you have a workload that preemption is harmful to.
> In the case of something like the Raspberry Pi changing the kernel if
> the distribution has not
On Sun, 2013-02-17 at 14:37 +, Jonathan Andrews wrote:
> > > The dim pixel code is timing critical (but as I said only a tiny
> > > fraction of the total CPU usage). What I need to do is grab the CPU and
> > > prevent any context switch (IRQ or PREEMPT) for this period.
> > why you want to do
> > The dim pixel code is timing critical (but as I said only a tiny
> > fraction of the total CPU usage). What I need to do is grab the CPU and
> > prevent any context switch (IRQ or PREEMPT) for this period.
> why you want to do this?
Because I need an I/O pin to change state for a short
The dim pixel code is timing critical (but as I said only a tiny
fraction of the total CPU usage). What I need to do is grab the CPU and
prevent any context switch (IRQ or PREEMPT) for this period.
why you want to do this?
Because I need an I/O pin to change state for a short accurately
On Sun, 2013-02-17 at 14:37 +, Jonathan Andrews wrote:
The dim pixel code is timing critical (but as I said only a tiny
fraction of the total CPU usage). What I need to do is grab the CPU and
prevent any context switch (IRQ or PREEMPT) for this period.
why you want to do this?
On Sun, Feb 17, 2013 at 02:37:24PM +, Jonathan Andrews wrote:
From a user perspective it seems a bit crap to have to change the kernel
if you have a workload that preemption is harmful to.
In the case of something like the Raspberry Pi changing the kernel if
the distribution has not done
On Sun, 2013-02-17 at 18:05 -0800, Greg KH wrote:
On Sun, Feb 17, 2013 at 02:37:24PM +, Jonathan Andrews wrote:
From a user perspective it seems a bit crap to have to change the kernel
if you have a workload that preemption is harmful to.
In the case of something like the Raspberry
On Sat, 2013-02-16 at 14:37 +, Jonathan Andrews wrote:
> I hope this is the correct place, I expect to get abused.
>
> I'm trying to do a mostly soft real-time task with a very small hard
> real time element.
>
> I've written some code to drive matrix LED signs using a Raspberry Pi.
>
>
I hope this is the correct place, I expect to get abused.
I'm trying to do a mostly soft real-time task with a very small hard
real time element.
I've written some code to drive matrix LED signs using a Raspberry Pi.
Source here:
I hope this is the correct place, I expect to get abused.
I'm trying to do a mostly soft real-time task with a very small hard
real time element.
I've written some code to drive matrix LED signs using a Raspberry Pi.
Source here:
On Sat, 2013-02-16 at 14:37 +, Jonathan Andrews wrote:
I hope this is the correct place, I expect to get abused.
I'm trying to do a mostly soft real-time task with a very small hard
real time element.
I've written some code to drive matrix LED signs using a Raspberry Pi.
Source
14 matches
Mail list logo
