<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.14.3"> </HEAD> <BODY> I back ported the fc8 (*23*) kernel to fc7 (64bit) and noted the following anomalies. When there are few processes running, performance is great. But, here is what I noticed and suffered with. Start pup. (downloading 12 updates). Started firefox and evolution only after pup started to do it's thing. 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. 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. 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. As I indicated, my observations are qualitative. I can't substantiate anything, so I may be completely wrong. 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). Do I like Fedora? You answer that question. <TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%"> <TR> <TD> Leslie Satenstein </TD> </TR> </TABLE> </BODY> </HTML>