Thanks. I'll try to back port locally.
Sushanth
--- On Tue, 4/10/12, John Baldwin wrote:
> From: John Baldwin
> Subject: Re: Startvation of realtime piority threads
> To: "Sushanth Rai"
> Cc: freebsd-hackers@freebsd.org
> Date: Tuesday, April 10, 2012, 6:57 AM
On Monday, April 09, 2012 4:32:24 pm Sushanth Rai wrote:
> I'm using stock 7.2. The priorities as defined in priority.h are in this
> range:
>
> /*
> * Priorities range from 0 to 255, but differences of less then 4 (RQ_PPQ)
> * are insignificant. Ranges are as follows:
> *
> * Interrupt thre
which explicitly sleeps at PUSER.
Sushanth
--- On Mon, 4/9/12, John Baldwin wrote:
> From: John Baldwin
> Subject: Re: Startvation of realtime piority threads
> To: "Sushanth Rai"
> Cc: freebsd-hackers@freebsd.org
> Date: Monday, April 9, 2012, 11:37 AM
> On
t; Thanks,
> Sushanth
>
> --- On Mon, 4/9/12, John Baldwin wrote:
>
> > From: John Baldwin
> > Subject: Re: Startvation of realtime piority threads
> > To: "Sushanth Rai"
> > Cc: freebsd-hackers@freebsd.org
> > Date: Monday, April 9, 2012,
I'm on 7.2. sched_sleep() on 7.2 just records the sleep time. That's why I
though _sleep might the right place to do the check.
Thanks,
Sushanth
--- On Mon, 4/9/12, John Baldwin wrote:
> From: John Baldwin
> Subject: Re: Startvation of realtime piority threads
> To: &
On Thursday, April 05, 2012 9:08:24 pm Sushanth Rai wrote:
> I understand the downside of badly written realtime app. In my case
application runs in userspace without making much syscalls and by all means it
is a well behaved application. Yes, I can wire memory, change the application
to use mu
d not adjust the priorities for realtime
threads.
Thanks,
Sushanth
--- On Thu, 4/5/12, John Baldwin wrote:
> From: John Baldwin
> Subject: Re: Startvation of realtime piority threads
> To: freebsd-hackers@freebsd.org, davi...@freebsd.org
> Date: Thursday, April 5, 2012, 9:01
On Thursday, April 05, 2012 1:07:55 am David Xu wrote:
> On 2012/4/5 11:56, Konstantin Belousov wrote:
> > On Wed, Apr 04, 2012 at 06:54:06PM -0700, Sushanth Rai wrote:
> >> I have a multithreaded user space program that basically runs at realtime
priority. Synchronization between threads are done
On 2012/4/5 11:56, Konstantin Belousov wrote:
On Wed, Apr 04, 2012 at 06:54:06PM -0700, Sushanth Rai wrote:
I have a multithreaded user space program that basically runs at realtime
priority. Synchronization between threads are done using spinlock. When running
this program on a SMP system und
On 2012/4/5 9:54, Sushanth Rai wrote:
I have a multithreaded user space program that basically runs at realtime
priority. Synchronization between threads are done using spinlock. When running
this program on a SMP system under heavy memory pressure I see that thread
holding the spinlock is sta
On Wed, Apr 04, 2012 at 06:54:06PM -0700, Sushanth Rai wrote:
> I have a multithreaded user space program that basically runs at realtime
> priority. Synchronization between threads are done using spinlock. When
> running this program on a SMP system under heavy memory pressure I see that
> thre
I have a multithreaded user space program that basically runs at realtime
priority. Synchronization between threads are done using spinlock. When running
this program on a SMP system under heavy memory pressure I see that thread
holding the spinlock is starved out of cpu. The cpus are effectivel
12 matches
Mail list logo
