On 11/08/07, <b class="gmail_sendername">Leslie Satenstein</b> <<a href="mailto:lsatenstein@videotron.ca">lsatenstein@videotron.ca</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



  
  

<div>
I back ported the fc8 (*23*) kernel to fc7 (64bit) and noted the following anomalies.  </div></blockquote><div><br>What do you mean by this? You backported fixes, you rebuilt the kernel with the f8t1 spec or you simply upgraded the kernel only from devel repos...?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
When there are few processes running, performance is great.  But, here is what I noticed and suffered with.<br>
<br>
Start pup. (downloading 12 updates).<br>
Started firefox and evolution only after pup started to do it's thing.  <br>
<br>
What I experienced was very very slow startup of both evolution and firefox(10 secs), with both the two timing out due to lack of responsiveness.  I think that the timeout appears to be due to the pup application hogging the cpu. 
</div></blockquote><div><br>Doubtful. More likely pup is hogging bandwith temporarily. Firefox and evolution are attempting to pull web and email data and are unable to do so, thereby slowing things down.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
I am guessing that pup has no timeslice max value to tell the process dispatcher to move it to the back of the dispatch queue, or the new process dispatcher in the *23* kernel doesn't know when it should to give control to the other waiting processes. 
</div></blockquote><div><br>I think you are guessing. If you mean CFS in 23 then you are off the mark. It certainly knows when to hand-off, that is its job.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
I think, by my guessing, that the timeout or response problems are due to fc7 applications that were built for the fc7 kernel (*22*), where the frequent clock interrupt in the kernel allowed the round robin execution to occur equitably.  I am surmising, probably very incorrectly, that the new kernel needs a new process dispatch algorithm which includes a max timeslice value for that process group. It could be there, but the fc7 applications were not built to communicate that way to the kernel's process dispatcher.
</div></blockquote><div><br>Please don't say things like this - its just nonsense. Better not to post to the list at all.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
As I indicated, my observations are qualitative. I can't substantiate anything, so I may be completely wrong.</div></blockquote><div><br>Then why post? <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
My environment:  Fc7 64 bit version, home use, 1 gig ddr2 memory, dual core processor (intel d930 -- 3gig hertz). Dual disks (one disk exclusive for 32bit fc7, the other exclusive for 64bit fc7).<br>
<br>
Do I like Fedora?  You answer that question.<br></div></blockquote></div><br>Eh? I'm really lost now.<br><br>Chris<br clear="all"><br>-- <br><a href="http://www.chruz.com">http://www.chruz.com</a>