From owner-freebsd-arch Wed May 16 15:23:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id F1B4C37B422 for ; Wed, 16 May 2001 15:23:23 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f4GMMpC81247; Wed, 16 May 2001 15:22:51 -0700 (PDT) (envelope-from dillon) Date: Wed, 16 May 2001 15:22:51 -0700 (PDT) From: Matt Dillon Message-Id: <200105162222.f4GMMpC81247@earth.backplane.com> To: Tor.Egge@fast.no Cc: arch@FreeBSD.ORG Subject: Re: on load control / process swapping References: <200105162135.f4GLZdo78984@earth.backplane.com> <200105162211.AAA02889@midten.fast.no> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :.. :> allow them to be reused in the next read(), and they will :> already be in the L2 cache. If I don't free the underlying VM :> pages the sequential read will force the L2 cache to cycle, and :> I'll bet that is why you get such drastically different idle :> times. : :Avoiding that copyout() is the major reason for increased idle time. : :The L2 cache will still cycle a lot with your suggested implementation :for the load I used since the normal amount of outstanding IO is 25 MB :(256 KB x 100). The L2 cache is a lot smaller then 25 MB. : :- Tor Egge I'd have to see your test code. Doing a direct-read into a user buffer has no cache impact at all (DMA does not go through the cpu cache). If you are doing seek/read()s but not actually looking at the data that is returned, your test results are going to be seriously skewed. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message