태스크릿은 sofrirq를 기반으로 작성되었으므로 둘은 매우 비슷하다. 반면 워크큐 메너니즘은 이들과 전혀 다르며 커널 스레드를 기반으로 구현된다.

softirq는 그 디장니상 가장 적게 시리얼라이즈 되어 있다. 따라서, softirq핸들러는 2개 이상의 그것도 같은 형식의 softirq가 서로 다른 프로세서에서 동시에 실행될 수 있음을 유의하여 공유 데이터의 안전에 필요한 부가적인 작업들을 추가해 주어야 한다.

만약 고려 대상이 코드가, 프로세서별로 할당된 변수들로 가득 찬 네트워크 서브시스템에서처럼 스레드를 이미 충분히 고려하였다면, sofrirq를 사용하는 것이 좋다.

osftirq는 타임크리티컬하고 자주 사용되는 코드를위한 갖아 빠른 해결책이다. 만약, 코드에 스레드에 대한 고려가 미비하다면, 태스크릿을 사용하느것이 낫다. 인터페이스가 간단하고, 같은 형식의 두 태스크릿이 동시에 수행되지 않으므로 ,ㄱ ㅜ현하기도 쉽다.

태스크릿은 사실상 동시에 수행되지 않는 softirq이다. 드라이버 개발자들은 softirq보다는 태스크릿을 사용해야한다.

내생각
softirq는 동기화가 되어있지 않다. 그러므로 다른 프로세서가 동일한 softirq를 수행할 수 있다.
반면에 태스크릿은 동기화 되어 있으므로, 한 프로세서만이 접근가능하다. 

프로세서별로 할당된 변수를 쓰거나 이와 유사한 방법으로 softirq가 여러 프로세서에서 동시에 안전하게 수행할 수 있도록 하지 못하는 한.

만약 지연된 작업이 프로세스 컨텍스트에서 수행돼야 한다면 워크큐가 유일한 해답이다. 만약 프로세스 컨텍스트가 꼭 필요치 않다면, 특히 휴면해야 할 필요가 없다면 softirq나 태스크릿이 보다 나은 성능을 보여줄 것이다. 워크큐는 세 보톰하프중에서 갖아 부담이 많은데, 왜냐하면 워크큐가 사용하는 커널 스레드는 컨텍스트 스위칭을 야기하기 때문이다. 물론 워크큐가 비효율적이라는 것은 아니지만 네트워크 서브시스템고 ㅏ같이 초당 수천번이 인터럽트가 발생하는 상황이라면 워크큐 이외의 방법을 사용하는 것이 좋다.

사용의 편의성은 워크큐가 좋다. 또한 기본적으로 제공되는 이벤트큐를 사용한다면 정말 누워서 떡먹기다. 다음은 간단한 인터페이스를 제공하는 태스크릿이고 마지막은 정적할당과 구현을 ㅟ한 심사숙고를 요구하는 softirq이다. 

보톰하프	컨텍스트	기본적인 Serialization
sotirq	interrupt	없슴
태스릿	interrupt	같은 태스크릿에 대해
워크큐	Process	없슴(프로세스 컨텍스트로 스케줄링됨)

드라이버 작성자는 두가지를 선택하면 된다.
1. 지연된 작업을 처리하기 위해 스케줄 가능한 요소가 필요한가, 즉 근본적으로 휴면해야할 필요가 있는가? 만약 그렇다면 워크큐가 유일한 해답이다. 그렇지 않다면 태스크릿을 사용한다. 오직 확장성이 문제되는경우만 softirq를 사용한다.