Re: Problem with SCHED_RR and kernel 2.4.18-4GB

Re: Problem with SCHED_RR and kernel 2.4.18-4GB

[Roger Larsson]

> I'm a newbie at Linux, but have been busy developing (with some other
> people) sort of a DVB zapper demo application/stack on top of Hauppauge HW
> and SUSE 8.0 kernel 2.4.18-4GB for the last 2 months.  
 
> As the stack wil eventually be ported to one (or more) dedicated HW
> platforms, we defined an OS independant API. Now, we want to be able to set
> priorities, and have sort of a realtime behaviour.  
 
> The problem is that if I implement this, and set scheduling to be SCHED_RR,
> or SCHED_FIFO, my linux machine hangs. With SCHED_OTHER, I don't have that
> (note that for testing I used to set all prios to minimum (=1)).  

The big difference is that if a tread running as SCHED_RR or SCHED_FIFO never 
sleeps normal treads (like X, sh, login, ...) will not be given ANY CPU time 
- computer will appear hanged.

[BTW you are not running the same code in both cases due to ifdefs...]

But it is possible to get out of this situation if you prepared for it 
before... Use a higher priority monitor to detect looping RT processes and 
reduce their priorities!

(I have code if you are interested, please CC me as I am not subscibed to 
linux-kernel)


/RogerL

 
-- 
Roger Larsson
Skellefteå
Sweden

Re: Problem with SCHED_RR and kernel 2.4.18-4GB

[g-j v dijk]

> > The problem is that if I implement this, and set scheduling to be 
>SCHED_RR,
> > or SCHED_FIFO, my linux machine hangs. With SCHED_OTHER, I don't have 
>that
> > (note that for testing I used to set all prios to minimum (=1)).
>
>The big difference is that if a tread running as SCHED_RR or SCHED_FIFO 
>never
>sleeps normal treads (like X, sh, login, ...) will not be given ANY CPU 
>time
>- computer will appear hanged.

Yep, I checked all threads. Not all threads have sleeps, but they do use 
semaphores or some blocking OS calls. Are you saying that's not enough? I 
think it should be, else the threads have design flaws.

>[BTW you are not running the same code in both cases due to ifdefs...]

Yep, IMHO you don't have to set the schedule type in "OTHER" mode.

>But it is possible to get out of this situation if you prepared for it
>before... Use a higher priority monitor to detect looping RT processes and
>reduce their priorities!

I like that Idea, it would be really appreciated if you could give me some 
sample code, just to get me started.

Thanks a lot,

Gert-Jan

_________________________________________________________________
MSN Search, for accurate results! http://search.msn.nl

Problem with SCHED_RR and kernel 2.4.18-4GB

[g-j v dijk]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

Hi All,

I'm a newbie at Linux, but have been busy developing (with some other 
people) sort of a DVB zapper demo application/stack on top of Hauppauge HW 
and SUSE 8.0 kernel 2.4.18-4GB for the last 2 months.

As the stack wil eventually be ported to one (or more) dedicated HW 
platforms, we defined an OS independant API. Now, we want to be able to set 
priorities, and have sort of a realtime behaviour.

The problem is that if I implement this, and set scheduling to be SCHED_RR, 
or SCHED_FIFO, my linux machine hangs. With SCHED_OTHER, I don't have that 
(note that for testing I used to set all prios to minimum (=1)).

I already read 2 issues/threads on the internet (that's all I could find 
closely related), but they didn't gave me the solution 
(http://www.ussg.iu.edu/hypermail/linux/kernel/0206.1/0946.html and 
http://www.cs.utah.edu/~regehr/hourglass/).

I already tinckered with it for a day now :-(

I checked whether all threads have an OS call (sem_lock, or sleep etc), to 
allow scheduling and not cause starvation of other processes/threads and yes 
that is the case and in IMHO this looks fine.

The questions:
1) Is this the right mailinglist for this question? If not, please direct me 
to the correct one, and I'm sorry for the inconvenience.
2) Attached a snippet of the code I made. Am i missing something obviously?
3) Is there a problem in 2.4.18? And if so, to which kernel should I move?

Thanks a lot,

Gert-Jan van Dijk

_________________________________________________________________
Play online games with your friends with MSN Messenger 
http://messenger.msn.nl/

[-- Attachment #2: gosy_thread_snippet.cpp --]
[-- Type: application/octet-stream, Size: 3460 bytes --]

#include <pthread.h> // include this first
#include <sched.h>
#include <errno.h>
#include <signal.h>
#include <sys/resource.h>
#include <sys/time.h>
#include <sys/wait.h>
#include <unistd.h>
#include <assert.h>
#include "gosy_thread.hpp"
#include "gosy_threadimpl.hpp"
#include "glog_logging.hpp"
#include "gosy_common.hpp"


/***************** cGosyThreadImpl *****************/


cGosyThreadImpl::cGosyThreadImpl(void)
{
    mRunning = false;

    if ( geteuid() != 0) // root
    {
        assert(false); // Must run as root, else we cannot change priority of task
    }
}

cGosyThreadImpl::~cGosyThreadImpl()
{
}

void *cGosyThreadImpl::StartThread(cGosyThread *pThread)
{
    pThread->StartThread();

    return NULL;
}
        

void cGosyThreadImpl::Start(int Priority, cGosyThread* pThread)
{
    int                 RetVal = 0;
                                // SCHED_OTHER (0 @ sched.h) -> Regular, non-realtime
                                // SCHED_RR    (1 @ sched.h) -> Round Robin, Realtime
                                // SCHED_FIFO  (2 @ sched.h) -> First-in First-out, Realtime
#   define              POLICY   (SCHED_FIFO)
    int                 Policy;
    pthread_attr_t      Attr;
    struct sched_param  SchedParam;

    assert( cGosyThread::GetMinPrio() <= Priority 
            && 
            cGosyThread::GetMaxPrio() >= Priority );
#if (POLICY != SCHED_OTHER)
    // SCHED_RR & SCHED_FIFO have prio between 1..99, so add 1 to priority of GOSY
    // as GOSY has prio between 0..15
    Priority = 1;
    assert( sched_get_priority_min(POLICY) <= Priority 
            && 
            sched_get_priority_max(POLICY) >= Priority );
#endif

    if (!mRunning)
    {
        mRunning    = true;

        RetVal = pthread_attr_init(&Attr);        
        assert( RetVal == 0 );

        // Detach state of thread will prevent "zombie processes" as no need
        // to join threads after cancellation.
        RetVal = pthread_attr_setdetachstate(&Attr, PTHREAD_CREATE_DETACHED);
        assert( RetVal == 0 );

#if (POLICY != SCHED_OTHER)
        RetVal = pthread_attr_setschedpolicy( &Attr, POLICY);
        assert( RetVal == 0 );
        SchedParam.sched_priority = Priority;
        RetVal = pthread_attr_setschedparam( &Attr, &SchedParam);  
        assert( RetVal == 0 );
#endif
        RetVal = pthread_create(&mThread, &Attr, (void *(*) (void *))&StartThread, (void *)pThread);
        assert( RetVal == 0 );

        RetVal = pthread_getschedparam(mThread, &Policy, &SchedParam);
        assert( RetVal == 0 );
        assert( Policy == POLICY );
#if (POLICY != SCHED_OTHER)
        assert( SchedParam.sched_priority == Priority );
#endif

        RetVal = pthread_attr_destroy(&Attr);
        assert( RetVal == 0 );
    }
}

int cGosyThreadImpl::SetPriority(int Priority)
{
    struct sched_param  SchedParam;
    int                 RetVal = 0;
    pthread_attr_t      Attr;

    if (Priority < cGosyThread::GetMinPrio()
        ||
        Priority > cGosyThread::GetMaxPrio())
    {
        return GOSY_WRONG_PRIO;
    }

#if (POLICY != SCHED_OTHER)
    assert(mRunning);

    RetVal = pthread_attr_init(&Attr);        
    assert( RetVal == 0 );

    SchedParam.sched_priority = Priority;
    RetVal = pthread_setschedparam(mThread, POLICY, &SchedParam);
    assert( RetVal == 0 );
#endif
}