diff --git a/core/sched.cc b/core/sched.cc
index 1994293ab63151425012aa49da366cdb166b02ce..103a25a0ef733005b25988badd2a234e008a74f4 100644
--- a/core/sched.cc
+++ b/core/sched.cc
@@ -93,22 +93,11 @@ void cpu::reschedule_from_interrupt(bool preempt)
     if (n != thread::current()) {
         if (preempt) {
             p->_fpu.save();
-        } else {
-            // FIXME: In this case, in theory, we do not need to save the FPU
-            // state (perhaps just mxcsr and cw) because we got here through a
-            // function call and the calling conventions guarantee the caller
-            // clears the FPU state. Unfortunately, in practice, the SPECjvm
-            // "sunflow" benchmark breaks (gets wrong results) if we don't
-            // save the SSE registers here. We don't know why.
-            p->_fpu.save();
         }
         trace_switch(n);
         n->switch_to();
         if (preempt) {
             p->_fpu.restore();
-        } else {
-            // FIXME: This shouldn't be here! See comment above.
-            p->_fpu.restore();
         }
     }
 }
diff --git a/todo/fpu b/todo/fpu
index bc20d5ed789b9e6629707eed80a46ba2eba58e04..080e2bfce98a05b388f19f77c6a38af317e79770 100644
--- a/todo/fpu
+++ b/todo/fpu
@@ -1,21 +1,5 @@
 Avoiding unnecessary FPU state saving
 =====================================
 
-1. Understand why the "sunflow" benchmark fails unless we also save FPU
-   state on reschedule_from_interrupt with !preempt:
-
-   1. One guess is that Java has a bug where it doesn't follow the calling
-      conventions and doesn't save its fpu state before calling some library
-      function. Avi tried to reproduce this in Linux (with a layer that
-      ruins the FPU state before calling library functions) and couldn't
-      so this may not be the correct explanation.
-
-   2. Another guess (by Avi) is that a signal handler is involved and
-      we don't save the FPU on signals! Need to fix that.
-
 2. Even if we don't need to save the whole fpu state on !preempt, we probably
    need to save the fcw and mxcsr.
-
-3. If for some reason (?) this problem is unfixable and we must (why?) save
-   FPU on every context switch, we may be forced to consider lazy FPU
-   switching - which we tried to avoid.