Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Jul 1999 19:36:10 -0400 (EDT)
From:      Zhihui Zhang <zzhang@cs.binghamton.edu>
To:        David Greenman <dg@root.com>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: reason for slow user-user memory copy 
Message-ID:  <Pine.GSO.3.96.990701192815.3735C-100000@sol.cs.binghamton.edu>
In-Reply-To: <199907012337.QAA07652@implode.root.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.96.990701192815.3735C-100000>