From owner-freebsd-hackers Thu Jul 1 16:48:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sol (cs1-gw.cs.binghamton.edu [128.226.171.72]) by hub.freebsd.org (Postfix) with SMTP id C928514D94 for ; Thu, 1 Jul 1999 16:48:17 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from localhost (zzhang@localhost) by sol (SMI-8.6/8.6.9) with SMTP id TAA03835; Thu, 1 Jul 1999 19:36:11 -0400 Date: Thu, 1 Jul 1999 19:36:10 -0400 (EDT) From: Zhihui Zhang To: David Greenman Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: reason for slow user-user memory copy In-Reply-To: <199907012337.QAA07652@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 1 Jul 1999, David Greenman wrote: > >A graduate student here implements a mmap() interface to a TCP/IP network > >card. He notices that it takes much longer time to copy from mmapp()'ed > >area to another user area than it takes to copy the same amount of data > >from kernel space to user space. The students here have no idea why this > >could be possible. I hope someone on this list can give us a hint. Below > >is a part of his original email. He uses rdtsc instruction to do the > >timing. > > > >------------------------------------------------------------------------ > >Well I have implemented a memory mapped interface for the user in Linux > >using the DEC 21140 Tulip ethernet card. Thus the user has access to the > >buffers, but when I did a memcpy from the RX buffer to the user variable, > >it took an extraordinary amount of time, approx 70 microsec for 1460 > >btyes... where as the original scheme takes 25 microsec for the same data > >when it does a memcpy_to_iovec in tcp_recvmsg(). > > > >I am confused by this unexpected timings. More than 80% of the time is > >spent doing the memcpy. > >----------------------------------------------------------------------- > > If the mapping is being done via a device mapping, then the region will > be marked non-cacheable. > > -DG I remember that he said he created a character device /dev/tulip to represent the network card. Actually, his work borrowed a lot from the Cornell U-Net project (now the basis of VIA?). Can we change the corresponding page table (directory) entries to be cacheable as needed? -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message