tasklet과 workqueue의 차이점

 커널 내의 코드를 짜다보면은 특정 작업을 다른 CPU에서 처리해야 하기도하고 어떤 작업은 몇미리 후에 처리 할 필요가 있는데 이런 경우 리눅스 커널에서는 tasklet과 workqueue라는 API를 사용해서 간단히 해결 할 수 있다. booklet, piglet 단어처럼 기존보다 작은 단위를 표현 할 때 let을 쓴다는 점으로 추측해볼 때 tasklet은 작은 일을 처리할 때 사용하는것 같고 같은 논리로 workqueue는 접미사로 queue가 있다는 점에서 미루어보아 작업(work)을 queue에 넣어서 처리하는 API인 것 같다. 

tasklet과 workqueue 모두 특정 작업을 미룰 수 있다는 점에선 동일하나 동작하는 매커니즘은 다르다. 먼저 tasklet은 softirq를 이용해서 동작한다. 세부 과정은 이렇다. tasklet이 스케줄 되면 스케줄러는 이 tasklet을 처리할 수 있는 CPU에게 softirq를 날리고 softirq를 받은 CPU는 하던 일을 멈추고 tasklet에서 설정된 작업을 수행한다. interrupt를 받은 상태로 동작하기 때문에 더 우선순위가 높은 interrupt가(ex. HW interrupt) 오지 않는 이상 tasklet의 작업을 모두 수행하기 전까지 다른 프로세스가 끼어들 수 없다. 만약 tasklet에서 처리하는 작업이 길고 남발하면 다른 작업들은 그만큼 뒤로 밀리게 돼 시스템 전반의 성능 저하가 올 수도 있다. 따라서 tasklet을 사용할 때는 가능한 짧게 수행 할 수 있는 작업을 써야한다. 이름을 참 잘지은 것 같다.

workqueue는 일반 프로세스가 스케줄링 되는 것과 비슷한 원리로 동작한다. workqueue를 관리하는 handler는 일반 프로세스처럼 CPU의 스케줄링을 받기 때문에 workqueue는 tasklet과 달리 작업이 끝나지 않았더라도 sleep에 들기도 한다. 작업을 모두 끝내기 전까지 CPU를 독점하는 tasklet에 비해서 처리하는데 시간이 오래 걸리지만(higher latency) 시스템에 무리를 줄 수 있는 요소가 없어 시간을 두고 처리해야하는 작업을 사용할 때 유용하다. 자유도가 더 높은 덕분인지 API의 기능도 tasklet에 비해서 많다.

	tasklet	workqueue
동작방식	Interrupt	Schedule
장점	처리가 빠르다	시스템에 무리가 없다
단점	시스템에 무리를 줄 수 있다	처리가 느리다

보다시피 tasklet과 workqueue는 수행하는 일 자체는 동일할 지 모르나 사용하는 상황은 다르다. 짧고 빠르게 수행해야 하는 작업(low latency)일 경우에는 tasklet을 사용해야 하는 반면 긴 시간을 두고 처리해야하는(high latency) 작업인 경우에는 workqueue를 사용하는 것이 좋다. 본인 작업의 성격에 따라서 tasklet과 workqueue를 잘 구분해서 사용하도록 하자.

다음 포스트에서는 tasklet과 workqueue의 사용법에 대해서 다루도록 하겠다.

* tasklet은 버전 2.3에, workqueue는 버전 2.5에 mainline에 포함됐다. 둘다 역사가 오래된 API이다.

* 참고사이트

- https://www.ibm.com/developerworks/library/l-tasklets/index.html IBM 블로그에서 정리를 아주 잘해뒀다. 돈내고 읽어야 할 것 같은 글인데.

- https://stackoverflow.com/questions/18321858/what-is-the-difference-between-tasklet-and-workqueue