인터럽트를 처리하기 위해선 Linux에선 3가지 방법이 있습니다.

softirq, tasklet, work queue

가 그것이죠.

인터럽트란 HW적으로 CPU에 interrupt를 만들어 무엇인가 처리해야 할일을 처리하게끔(?) 만드는 역할을 합니다. 키보드를 누를때도 인터럽트가 발생하고, USB에 장치를 연결해도, 심지어 time tick을 처리하기 위해서도 1초에 300번정도(커널설정에 따라 변경 가능(i.e. 1000)) HW interrupt가 발생합니다. HW적으로 인터럽트핀이 CPU를 깨워서 인터럽트가 걸리면 맨앞 핸들러로 뛰어서 어떤인터럽트가 걸렸는지 확인하는 루틴이 실행됩니다. 이 루틴안에서 어떤 인터럽트인지 확인하고 다음처리를 담당하게 되죠. 그러나 주위해야하는점은 어떤 HW 인터럽트가 먼저 걸렸을때엔 다른 HW 인터럽트가 걸리지 않게 됩니다(인터럽트 pin을 SW적으로 내리기 전까진). 즉,응답성을 위해선 인터럽트 핸들러에선 정말 간단하게 어떤 인터럽트인지만 확인하고, 바로 인터럽트를 해제하지 않으면 그사이엔 어떠한 HW 인터럽트가 발생되지 않아 시스템의 응답성이 떨어지게 되겠죠.. 바로 HW인터럽트를 받아서 인터럽트핀을 해제하고 약간 지연되게 처리하는 방법이 위의 3가지라고 보시면 됩니다.

softirq

32가지 미리 정의된 인터럽트들을 정의하고, 인터럽트 핸들러가 종료되서 인터럽트 가능한 상태로 바뀌면 바로 softirq가 실행된다. 가장 높은 우선순위를 가지고 있으며, 고정된 인터럽트들을 처리하기 위해서 사용합니다. 현재 커널은 32가지중 6가지만 사용합니다. 종류는 HI_SOFTIRQ(높은 우선순위), TIMER_SOFTIRQ(타이머), NET_TX_SOFTIRQ(네트워크 패킷송신), NET_RX_SOFTIRQ(네트워크 패킷수신), SCSI_SOFTIRQ(SCSI), TASKLET_SOFTIRQ(태스크릿들)이고, HI_SOFTIRQ가 우선순위가 가장높게 처리됩니다.

tasklet
동적으로 할당된 softirq라고 생각하면 됩니다. 위 softirq의 SCSI_SOFTIRQ가 처리되고나서 TASKLET_SOFTIRQ가 처리되는데 이때엔 동적으로 할당을 받아서 처리하고 싶은 handler를 등록하고 처리하게 됩니다.

work queue
softirq나 tasklet들이 실행중에는 sw인터럽트중이라, hw 인터럽트는 가능하지만, 여전히 sw적으로 우선적으로 처리되는것들입니다. 즉 softirq중에는 user process들이나, context switch등은 처리되지 않고 있겠죠. 모든 sw irq를 softirq로만 처리한다면 user process나 context switch등은 처리안되어 유저입장에선 상당히 반응성이 안좋은 커널이라 생각할수 있습니다. 그래서 context switch등과 동일한 level에서 스케쥴링되는 work queue를 두어 sw interrupt들이지만 상당히 시간을 요하거나 계산해야될게 많은 작업들 혹은 휴면이 필요한 I/O작업이 필요한 일들은 context switch될때 같이 되게 만들어 주어 커널 응답성을 좋게 해줄수 있습니다.

출처 : http://kldp.org/node/112272

프로세스마다 인터럽트 처리 방식이 다르기 때문에 리눅스 커널에서는 동일하게 처리하기 위해 IRQ 인터럽트는 모두 do_IRQ() 함수를 호출하여 처리하도록 되어 있다. 이 do_IRQ() 함수는 오직 IRQ 처리만 담당하며, irq_desc라는 전역 변수에 등록된 인터럽트 서비스 함수를 호출하는 구조로 되어 있다.디바이스 드라이버나 커널에서 IRQ 인터럽트 처리가 필요한 경우에는 처리하고자 하는 IRQ 번호에 해당하는 인터럽트 서비스 함수를 이 irq_desc 전역 변수에 등록하면 된다.

IRQ 인터럽트 서비스를 처리하기 위해서는 request_irq() 함수를 이용하여 처리하고자 하는 IRQ 번호와 서비스 함수 주소를 등록한다. 인터럽트가 발생하면 커널은 아키텍처마다 고유의 IRQ 검출 루틴을 이용하여 발생된 인터럽트의 IRQ 번호를 획득하여 do_IRQ() 함수를 호출한다.

더이상의 인터럽트 처리가 필요없는 경우에는 하드웨어에서 인터럽트가 더이상 발생하지 않도록 처리한 후 free_irq() 함수를 이용하여 irq_desc 전역 변수에 등록된 인터럽트 서비스 함수를 제거한다.

. 커널 2.4

. #include <linux/sched.h>

. void int_handler(int irq, void* dev_id, struct pt_regs* regs)

{

}

. int request_irq(unsigned int irq, void (*handler)(int, void*, struct pt_regs*), unsigned long frags, const char* device, void* dev_id);

. void free_irq(unsigned int irq, void* dev_id);

. 커널 2.6

. #include <linux/interrupt.h>

. irqreturn_t int_hander(int irq, void* dev_id, struct pt_regs* regs)

{

    return IRQ_HANDLED;

}

. int request_irq(unsigned int irq, irqreturn_t(*handler)(int, void* struct pt_regs*), unsigned long frags const char* device, void* dev_id);

. frags

    . SA_INTERRUPT             다른 인터럽트를 허가하지 않느다

    . SA_SHIRQ                    동일한 인터럽트 번호를 공유한다

    . SA_SAMPLE_RANDOM  랜덤값 처리에 영향을 준다

. dev_id

    . 인터럽트 ID를 뜻하는 것으로 인터럽트 공유에 사용되거나 인터럽트 서비스 함수를 수행할 때 필요한 정보가 저장된 메모리의 선두 주소를 담고 있다.

    . 인터럽트 서비스 함수를 등록할 때 지정된 값이 그대로 전달된다.

. regs

    . 인터럽트가 발생한 당시의 레지시터 값들

* 인터럽트 서비스 함수 내의 메모리 할당

vmalloc() 함수나 vfree() 그리고 ioremap() 같은 함수를 인터럽트에서 사용하면 안 된다. kmalloc() 함수 역시 GFP_ATOMIC 인자를 사용한 방식만 사용해야 한다는 제약이 있다.

* 인터럽트 서비스 등록과 해제 시점

왜 open()함수와 close()함수에서 인터럽트 서비스 함수 등록과 해제 루틴을 넣을까?

모듈이 초기화될 때 서비스 함수가 등록되면 해당 디바이스를 사용하는 응용 프로그램이 없다 하더라도 인터럽트가 발생하면 인터럽트 서비스 함수가 항상 호출된다. 이런 호출 방식은 전체 시스템의 처리 속도를 약간 느리게 만드는 원인이 된다. 그래서 open() 함수나 close() 함수에서 인터럽트 서비스 함수의 등록과 해제가 이루어지도록 해야 한다.

PC 같은 범용 시스템에 사용되는 디바이스 드라이버를 만든다면 open() 함수와 close() 함수에서 처리해야 하고, 임베디드와 같은 특정 목적의 시스템에서는 모듈의 등록과 해제 시에 처리하는 것이 좋다.

* 인터럽트의 공유

인터럽트 서비스 함수를 등록할 때 같은 인터럽트 번호에 대해 다른 인터럽트 서비스 함수를 등록할 수 있도록 지원한다.

. frags : SA_SHIRQ가 포함되어야 하고

. dev_id : 동일한 인터럽트 서비스 함수를 구별하기 위해 0이 아닌 값을 사용해야 한다.

* 인터럽트의 금지와 해제

-. 인터럽트 서비스 함수가 동작중에 다른 인터럽트가 발생하지 못하게 막는 경우

. frags 매개변수에 SA_INTERRUPT를 포함시킨다. 인터럽트가 발생했을 때 SA_INTERRUPT 값이 포함된 인터럽트 서비스 함수는 커널이 프로세스의 인터럽트를 금지시킨 후 호출한다.

-. 일반적인 함수 수행중에 데이터 처리를 보호하기 위해 인터럽트를 강제로 막는 경우

. 특정 인터럽트 번호에 대한 금지와 해제

    . #include <asm/irq.h>

    . void disable_irq(int irq) : 인터럽트 금지

    . void enable_irq(int irq) : 인터럽트 허가

. 전체 인터럽트를 금지하고 해제

    . #include <asm/system.h>

    . 커널 2.4

        . cli(void) : 프로세서의 인터럽트 처리를 금지한다.

        . sti(void) : 프로세서의 인터럽트 처리를 허가한다.

        . save_flags(unsigned long frags) : 현재의 프로세스의 상태를 저장한다.

        . restore_flags(unsigned long frags) : 저장된 프로세스의 상태를 복구한다.

    . 커널 2.6

        . local_irq_disable(void) : 프로세서의 인터럽트 처리를 금지한다.

        . local_irq_enable(void) : 프로세서의 인터럽트 처리를 허가한다.

        . local_save_flags(unsigned long frags) : 현재의 프로세스의 상태를 저장한다.

        . local_restore_flags(unsigned long frags) : 저장된 프로세스의 상태를 복구한다.

        unsigned long frags;

        local_save_flags(frags);

        local_irq_disable();

        // 인터럽트 호출에서 보호하고자 하는 루틴

        local_restore_flags(frags);

        . local_irq_enable() 함수를 사용하지 않는데, 그 이유는 local_save_flags() 함수에 의해 저장된 frags 변수에는 이미 인터럽트 허가 상태가 포함되어 있기 때문이다. 그래서 굳이 local_irq_enable() 함수를 사용하지 않아도 local_restore_flags() 함수에 의해 local_irq_disable() 함수를 호출한 효과가 발생한다.

* 인터럽트 발생 횟수

인터럽트 발생 횟수는 커널이 알아서 계산한다. /proc/interrupts란 파일을 보면 현재 인터럽트의 발생 횟수를 볼 수 있다.

# cat /proc/interrupts

출 처 http://blog.naver.com/jinynet9?Redirect=Log&logNo=40013761955

4. 모듈 파라미터 처리

모듈은 command line에서 인자들을 받을 수 있다. 인자를 모듈로 넘기기 위해서는 module_param() 매크로를 사용하여 변 수 를 선 언 하 여 야 한 다 . 예 를 들 어 “ insmod

hello_world_parm.ko myarg1=1”같이 int형의 하나의 인자를 넘기기 위해서는 커널의 모듈 코드에 다음과 같이 선언해야 한다.

int myarg1 = 0

module_param(myarg1, int, 0);

module_parm 매크로는 변수의 이름, 타입, sysfs의 관련된 파일의 permission 이렇게 3개의 인자를 갖는다. 인자로 배열을 넘기는 방법은 약간 다르다. 먼저 매크로는

module_param_array를 사용하며 4개의 인자를 갖는다. 3번째 인자로 배열의 갯수를 받을 수 있는 변수를 추가되었다.

int myarg2 [4];

int count;

module_parm_array(myarg2, int, &count , 0);

인자의 갯수를 특별히 받고 싶지 않다면 단순히 NULL을 사용하면 된다.

다음, 모듈의 파라미터를 설명하기 위한 MODULE_PARM_DESC() 매크로가 있다. 이것은 모듈을 사용하는 사람을 위해서 인자를 설명하기 위한 방법이다. 이것은 변수의 이름과 그 변수를 설명하는 문자열을 받게 된다.

MODULE_PARM_DESC(myarg2, "This is int array forI/O port data");

위의 모든 것을 다 포함해서 hello_world2를 만들어 보자.

#include <linux/module.h>

#include <linux/moduleparam.h>

#include <linux/kernel.h>

#include <linux/init.h>

#include <linux/stat.h>

MODULE_LICENSE("GPL");

MODULE_AUTHOR("you");

static int argint = 1;

static char *argstring = "This is a string";

static int argarray[2] = { 0, };

static int size_argarray= 0;

module_param(argint, int, S_IRUSR | S_IWUSR |

S_IRGRP | S_IWGRP);

MODULE_PARM_DESC(argint, "A short integer");

module_param(argstring, charp, 0000);

MODULE_PARM_DESC(argstring, "A character string");

module_param_array(argarray, int, &size_argarray,

0000);

MODULE_PARM_DESC(argarray, "An array of

integers");

static int __init hello_init(void)

{

int i;

printk(KERN_EMERG "argint : %d ", argint);

printk(KERN_EMERG "argstring : %s ", argstring);

for (i = 0; i < (sizeof (argarray) / sizeof (int)); i++)

{

printk(KERN_INFO "argarray [%d] : %d ", i,

argarray [i]);

}

printk(KERN_INFO "argarrary size : %d ",size_argarray);

return 0;

}

static void __exit hello_exit(void)

{

printk(KERN_EMERG "Goodbye, world ");

}

module_init(hello_init);

module_exit(hello_exit);

위의 코드를 컴파일 한 후 실행하기 전에 modinfo를 통해 모듈의 정보를 확인해보자.

root@barrios-desktop:~/example/module2# modinfo

hello_world.ko

filename: hello_world.ko

license: GPL

author: you

vermagic: 2.6.18 SMP mod_unload 586 REGPARM gcc-4.1

depends:

srcversion: 300231DCA83E809D0F54644

parm: argarray:An array of integers (array of int)

parm: argstring:A character string (charp)

parm: argint:A short integer (int)

위와 같이 이전에 비하여 많은 정보들이 출력되는 것을 볼 수 있다. 이 중에는 여러분들이 파라미터를 설명하는문자열도 출력된다. 이번에는 모듈을 로드해보자. 무엇이 출력되는가?

root@barrios-desktop:~/example/module2# insmod

hello_world.ko argint=100 argstring="hey"

argarray=100,200

여러분들의 예상이 맞는가?

출처 : http://www.linux.co.kr/home2/board/bbs/board.php?bo_table=lecture&wr_id=1640&sca=1&sca2=32

spinlock_t - SpinLock을 위한 자료구조

spin_lock(slp) - SpinLock을 획득

spin_unlock(slp) - SpinLock을 해제

spin_lock_init(slp) - SpinLock을 해제된 상태로 초기화 

spin_trylock(slp) - SpinLock을 획득하기위해 시도를 하고, 성공하면 1, 실패하면 0을 돌려줌 

spin_unlock_wait(slp) - SpinLock이 풀릴 때까지 기다린다. 

spin_lock_irq(slp) - 인터럽트를 금지시키고, SpinLock을 획득

spin_unlock_irq(slp) - SpinLock을 해제하고, 인터럽트금지를 해제 

spin_lock_irqsave(slp, flags) - 인터럽트플래그를 저장하고, 인터럽트를 금지하고, SpinLock을 획득 

spin_unlock_irqrestore(slp, flags) - SpinLock을 해제하고, 인터럽트플래그를 복구하며, 인터럽트금지를 해제 

어디서 가져온 자료인지 기억이 안나요...ㅜ..ㅜ

죄송합니다..;;

출처 : http://blog.naver.com/wjdguddnr00?Redirect=Log&logNo=20018016177

SpinLock이란?

Spin Lock 은 이름이 뜻하는대로, 만약 다른 스레드가 lock을 소유하고 있다면 그 lock이 반환될 때까지 계속 확인하며 기다리는 것이다.

Spinlock은 다음과 같은 특성을 갖는다.

1. Lock을 얻을 수 없다면, 계속해서 Lock을 확인하며 얻을 때까지 기다린다. 이른바 바쁘게 기다리는 busy wating이다.
2. 바쁘게 기다린다는 것은 무한 루프를 돌면서 최대한 다른 스레드에게 CPU를 양보하지 않는 것이다.
3. Lock이 곧 사용가능해질 경우 컨택스트 스위치를 줄여 CPU의 부담을 덜어준다. 하지만, 만약 어떤 스레드가 Lock을 오랫동안 유지한다면 오히려 CPU 시간을 많이 소모할 가능성이 있다.
4. 하나의 CPU나 하나의 코어만 있는 경우에는 유용하지 않다. 그 이유는 만약 다른 스레드가 Lock을 가지고 있고 그 스레드가 Lock을 풀어 주려면 싱글 CPU 시스템에서는 어차피 컨택스트 스위치가 일어나야하기 때문이다

 출처 : http://devnote.net/wiki/index.php/Spinlock

즉, 멀티코어CPU 환경에서 Lock을 소유하고 있는 시간이 매우 순간일 경우에 Critical Section이나 Mutex대신에 사용하면 더욱 좋은 성능을 기대 할 수 있다.

SpinLcok 구현

Lock을 걸때는 ::InterlockedCompareExchange를 이용하여 현재 소유한 threadid가 없을경우 내threadid로 설정을 시도한다.
내 threadid로 설정을 하지 못하면 계속해서 loop를 돌면서 시도를 한다.
이 때, loop를 너무 오랜시간 동안 돌면 오히려 성능이 나빠질 수 있으니, 적절히 Sleep를 사용할 수 있도록 한다.
(loop 를 돌때마다 Sleep을 사용한다면 컨택스트 스위칭이 일어나 SpinLock이 무용지물이 될 가능성이 많다)

UnLock 에서는 소유한 threadid를 해제시켜주기만 하면 된다.

위의 소스에서는 Recursive Call을 할경우에 DeadLock이 걸린다.
Recursive Call을 지원하기 위해 아래와 같이 수정하였다.

성능 테스트

그럼 이제 실제로 Critical Section과 SpinLock의 성능 차이를 테스트 하였다.
(테스트 방법에 따라 결과가 달라질 수 있음)

  - 테스트 환경 : 듀얼코어 CPU
  - 방법 
    1) std::map<int,int>을 하나 생성해서 1~1000000까지 키를 입력
    2) 각 쓰레드는 1~1000000까지 루프를 돌면서 map에서 find실행 이때, find한번당 Lock, UnLock을 호출하며, 루프가 종료되는데 걸린 시간을 측정
          for ( int iFind=0; iFind<1000000; ++iFind)
         {
          // Lock
              std::map<int, int>::const_iterator itr = g_map.find(iFind);
          // UnLock
          }
    3) 쓰레드 3개를 만들어서 결과 측정


측정결과는 예상대로 Critical Section을 사용하는 것 보다 SpinLock을 사용하는 것이 성능향상이 있었으며,
성 능향상율은 평균 20%정도나 되었다.

< Critical Section을 사용했을 때>

< SpinLock을 사용 했을 때 >

SpinLock.zip

출처 : http://yonmy.com/xe/blog/646