kkamagui의 작업실

태스크 부하 분산(Task Load Balancing)을 구현하는 중인데... PIT 컨트롤러의 인터럽트에서 스케줄러의 상태를 보고 태스크가 적은 곳에 집어 넣는 방법을 사용했습니다. 그런데 ㅡ_ㅡa... 이게 문제가 있네요. 난데없이 집어 넣은 스케줄러에서 실행되는 것이 아니라 다른 스케줄러에서 튀어나오질 않나... 같이 스핀락을 획득하는 부분이 없는데 데드락이 발생하지 않나... ㅡ_ㅡa... 그것 때문에 어제 밤 9시경부터 오늘 아침 8시까지 디버깅했습니다. 결과는 GG ㅠㅠ

디버깅을 미친 듯이 한 덕분에 오후 3시쯤 느즈막하게 일어났군요. 당췌... 이게 무슨 일인지... 다 해 놓고 막판에 테스트할 때 이런 문제가 나오면... 어흑... ㅠㅠ 그나마 GUI로 넘어가기 전에 발견했기에 망정이니... 아니면 큰일날 뻔 했습니다.

어휴 진짜... 증상은 있는데... 원인을 정확히 알 수가 없네요. ㅠㅠ 스핀락에 문제가 있는 것도 아니고... 코어가 많아서 그런 현상이 발생한다고 보기에는 뭔가 미심적인 부분이 있습니다(16개 코어 + 800개 태스크로 테스트를 하고 있답니다. ㅎㅎ). 그래서 방향을 선회해야겠는데... 시간이 좀 촉박한지라 고민을 계속 하고 있습니다. 오늘 안에 결과가 나오면 좋겠는데... 과연 잘 될지 모르겠네요. ^^;;;;

일단 또 작업을 시작해야겠습니다. ㅎㅎ 저녁쯤에는 글 하나를 더 쓸 수 있으면 좋겠군요 ㅠㅠ)-b

헥헥... 이번에는 거의 3주 만에 블로그에 글을 올리네요.  ㅠㅠ 점점 글 올리는 주기가 길어지는 걸 보니 조만간 폐허(?)가 되는 게 아닌가 걱정되는군요. ㅠㅠ 정말 블로그에 글 올릴 시간도 없이 열심히 작업했는데, 이제야 겨우 끝났습니다. 사실 코딩하는 데는 이틀 밖에 안 걸렸지만 내용 정리하는데 12일 정도가 걸렸군요. ㅡ_ㅡa... 회사를 다니고 있으니 야간에 작업을 해야 하는데, 그래서 더 어려운 것 같습니다. (이거 원... 잘하면 회사도 때려 치겠군요. 쿨럭..;;;;)

이번에 추가된 기능은 프로세서 내에 잠자고 있는 나머지 코어를 깨우는 일이었습니다. 보통 부팅을 시작하면 BIOS가 코어 중에서 하나만 선택해서 BSP(Bootstrap Processor)로 만든 후 부팅을 시키고, 나머지는 AP(Application Processor)로 만들어 대기시킵니다. BSP는 부팅이 끝나면 MP Configuration Table 같은 걸 읽어서 잠자고 있는 AP의 수를 계산한 뒤 나머지를 깨워서 일을 시키는 것이지요.

MP Configuration Table을 분석하는 작업은 지난 번에 했으니, 이번에는 이 정보를 바탕으로 AP를 활성화했습니다. 아래 그림은 총 16개의 코어를 활성화하여 각자가 메시지를 출력하게 한 것입니다.

 <총 16개의 프로세서(BSP 1개, AP 15개)가 동시에 동작하는 화면> 

아아~ 정말 작업하는 게 쉽지 않군요. 별다른 동기 부여 없이도 꾸준히 하는 스타일인데... 요즘은 살짝 지치는 느낌입니다. 아무래도 배보다 배꼽(?)이 더 큰 상황 때문이 아닐까 생각하는데... 앞으로 MileStone 2개 정도만 더 올리면 GUI라서 꾹 참고 진행하고 있습니다. ;)

에궁... 다음 MileStone은 BSP와 AP가 동시에 인터럽트 처리를 하는 것이 될 것 같습니다. 이것만 지나가면 AP에도 스케줄러를 붙여 멀티 태스킹 시킬 수 있으니... 거의 끝난 것이죠. ;) 아유~ 지겹네요. ㅠㅠ 그래도 열심히 해야지... 어쩌겠습니다. 어흑...

장마 전선이 올라왔다던데... 다들 비 피해 주의하시고 건강 잘 챙기세요 ;)

ps) 곧 GUI로 들어간다니 여자 친구가 MINT64 OS에서 쓸 바탕 화면을 디자인해 줬습니다.이 중에 하나를 택해야 할 것 같은데... 어떤 것이 좋을까요? ;)