Dropsafe

by Alec Muffett

OSX Kernel Scheduler Bug?

maybe-osx-kernel-bug.png

I am currently hammering my MacBook Air; it is doing a Final Cut render, and compiling gettext and GIMP; all of this is user-space intensive and there is a modest amount of I/O going on, so why is the kernel process eating 75% of one of my two cores?

I have seen this before, when I was running 5 simultaneous “ffmpeg” processes (which have no kernel magic unlike Quicktime/FinalCut, so therefore it *cannot* be a in-kernel-acceleration-thing, can it?) and I don’t think it was paging for memory, either. Likewise, in that case, the resultant files were no more than 5x 20..50Mb written over the span of 20 minutes, so it’s not likely to be a matter of IO interrupts.

Maybe this is a A/SMP scheduler conflict? I need a dtrace expert to help me find out…

⊞

Comments

3 responses to “OSX Kernel Scheduler Bug?”

  1. alecm
    $vm_stat 3

Mach Virtual Memory Statistics: (page size of 4096 bytes, cache hits 89%)
  free active inac wire   faults     copy    zerofill reactive  pageins  pageout
120936 273687 42684 85246    73181    10199    33155        0        0        0
120542 274662 42694 84608    71887     8678    37776        0      617        0
116188 279312 42694 84639    39586      341    31610        1     1833        0
117179 277583 42697 85266    43350     1599    28401        0       53        0
118484 276753 42702 84711    49077     3173    33178        0       39        0
118681 276435 42710 84710    52800     3709    35377        0        0        0
117756 277562 42710 84711    38830     1491    30770        0        0        0
117026 278014 42710 84712    43603     1489    36175        0        0        0
119456 275969 42710 84696    53527     3431    37567        0        0        0
117717 277528 42710 84799    38002     1775    28362        0        5        0
116225 279017 42784 84719    33358      742    29138        0      143        0
115197 280095 42784 84721    30923        0    30825        0        0        0
117180 278062 42784 84718    48488     2234    37312        0        0        0
    Reply
  2. Chris Samuel

    I’d say that it’s down to disk I/O, top is showing almost 50% of the time in system calls and that reeks of I/O issues.

    What does iostat say ?

    Reply
  3. Stephen Usher

    Why not run Dtrace on it?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts