> Thank you for your suggetion.
> > Even if it is possible, what machanism will maintain coherency between the
> > cache and the remote memory which is seen through the system that has been
> > described in the initial mail.
> Of course, I understand coherency issue.
> Since this system is early experimental, we force strong limitation to
> application programmer (i.e. before reading buffer mapped to remote node's
> memory, application explicitly must invalidate cache associated.)
> Finally, we will implement coherency mechanism on NIC (hopefully...).
> Also, I understand PCI mastar capable device is the appropriate solution
> for these performance issue, but I'd like to try squeeze out performance
> from current H/W implementation as possible as I can.
> Before Linux implementation, my colleague wrote very basic device
> driver on Windows/NT. On WIndows/NT, he can map such PCI address space
> (finally mapped to remote node's memory) as Cachable,
> and observed 'Read Multiple' (or 'Read Line' not sure, sorry) transaction
> on PCI bus (monitored with PCI analyzer).
If this is possible under Windows/NT, then it is also possible under
Linux. Linux-2.1.x provides a user interface to set MTRRs.
I only have data sheets from Intel on Host bridges. In this data sheets
only the ability to coalesce writes into a burst is described and is
called 'combining'. In the architecture manuals of PII, aligned rep memory
copies are also described as able to handle cache lines moves.
Cacheable means at least read-caching. But you can use Write-Through or
Write-Back caching. If your application can cope about cache coherency
problems, and the host bridges performs prefecthing from PCI address range
defined as cachable, then everything will be as fine for you under Linux
as under Win/NT.
> So, I'd like to implement same feature (access method) on Linux (if possible).
Based on your description, I think this should be possible. Your driver
will certainly have to provide to applications a memory mapping service
for the PCI address range that is to be handled from user-land.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/