I'll try to track down an actual PCIe card rather than a simulator and
run down some numbers on Monday.
Paul
On 5-Dec-08, at 12:11 PM, ron minnich wrote:
On Fri, Dec 5, 2008 at 11:30 AM, Paul Lalonde <[EMAIL PROTECTED]>
wrote:
But random access patterns suck at being speculatively cached
On Dec 2, 2008, at 5:36 PM, Dan Cross wrote:
On Tue, Dec 2, 2008 at 7:07 PM, erik quanstrom
<[EMAIL PROTECTED]> wrote:
currently one can prevent external changes to a
namespace by creating a unique ns with rfork.
if /proc/$pid/ns were writable, one would not not
be possible without yet another
On Dec 4, 2008, at 8:43 PM, erik quanstrom wrote:
On Thu Dec 4 23:37:02 EST 2008, [EMAIL PROTECTED] wrote:
supported 400 users on 120 workstations in 1984; this
evening CMU's AFS cell hosts 30,821 user volumes, roughly
half a gigabyte each; there are cells with more users and
cells with more bi
On Dec 4, 2008, at 8:35 PM, Dave Eckhardt wrote:
At some distant point in the past (last century, actually)
I was drawn to AFS because of the features, but left in
horror because of the complexity.
The goal was adding an enterprise-scale distributed file
system to an existing operating system (
Or another quick way to find it:
src -s parseip ip/ipconfig
I'm addicted to google code search now:
http://www.google.com/codesearch?hl=en&lr=&q=+ulong+parseip&sbtn=Search
On Fri, Dec 5, 2008 at 3:27 PM, Ishwar Rattan <[EMAIL PROTECTED]> wrote:
>
> Can any one point me to the file containing
> code for: ulong parseip(uchar *ipaddr, char *str)
> described i
/sys/src/libip/parseip.c
- erik
Can any one point me to the file containing
code for: ulong parseip(uchar *ipaddr, char *str)
described in ip(2)..
-ishwar
i'm surprised: i ran plan 9 on my atom board. unfortunately that one is in
production
use now so i can't test it with the latest iso. i've got another not yet in use
that i can try, but not until monday.
Hi,
I've got my hands on a Intel Atom D945GCLF [1] board and I'm trying
to install Plan 9 on it. It's my first time so please be gentle. ;D
I'm using the Dec 5 2008 iso and it hangs on the following:
[...]
1014M memory: 256M kernel data, 758M user, 1383M swap
kfs...version...time...
qlock: 0xf0
On Fri, Dec 5, 2008 at 11:30 AM, Paul Lalonde <[EMAIL PROTECTED]> wrote:
> But random access patterns suck at being speculatively cached.
> Linear access patterns still require reasonably careful work for the caching
> to do the right thing.
> Expecting your entire frame buffer to be cached in L2 i
On Fri Dec 5 14:32:56 EST 2008, [EMAIL PROTECTED] wrote:
> But random access patterns suck at being speculatively cached.
> Linear access patterns still require reasonably careful work for the
> caching to do the right thing.
> Expecting your entire frame buffer to be cached in L2 isn't particula
But random access patterns suck at being speculatively cached.
Linear access patterns still require reasonably careful work for the
caching to do the right thing.
Expecting your entire frame buffer to be cached in L2 isn't particularly
reasonable.
Paul
erik quanstrom wrote:
On Fri Dec 5 14:
On Fri Dec 5 14:23:22 EST 2008, [EMAIL PROTECTED] wrote:
> Again, you can stream a whole frame buffer reasonably fast - that should
> be nearly full-rate; it should be full rate if you pre-fetch with
> sufficient advance notice (500-1000 clocks), or DMA. But random access
> reads *have* to be
Again, you can stream a whole frame buffer reasonably fast - that should
be nearly full-rate; it should be full rate if you pre-fetch with
sufficient advance notice (500-1000 clocks), or DMA. But random access
reads *have* to be slow: you get a stall while the system goes to PCIe
for each cach
On Fri, Dec 5, 2008 at 10:32 AM, Russ Cox <[EMAIL PROTECTED]> wrote:
> To a first approximation, no one reads directly from video memory.
That is certainly true, but it's been a concern for some time for GPU
computing, and the chipset folks are paying attention.
ron
On Fri, Dec 5, 2008 at 10:27 AM, Russ Cox <[EMAIL PROTECTED]> wrote:
>> i don't think this is the case. if you recall from the original
>> post, i have used the pat registers to set up memory types on
>> a pcie card and i do see dramatic speedups for drawing to
>> the screen. however, reading fro
> i don't think this is the case. if you recall from the original
> post, i have used the pat registers to set up memory types on
> a pcie card and i do see dramatic speedups for drawing to
> the screen. however, reading from the screen is just as slow
> as before.
I think the problem of
> can
> If you're still seeing bad performance it may be because you need to
> fix up the MTRR or GART settings. I've done this dance and have no
> memory at this point of what you do, but vague memory is that proper
> MTRR settings with a good PCIe card will give you far better bandwidth
> than the old
Personally, I'm a big fan of Heinlein and would like to recommend the
following of his works:
Starship Troopers (my favourite book)
The Moon is a Harsh Mistress
The Door into Summer
Space Family Stone (yes it is dead cheesy, but we all have our guilty pleasures)
No one seems to have mentioned Kim
> It might be an interesting project for some student(s) to reimplement
> Kerberos 5 for Plan 9... it's something of an open question of just how
> minimal and tasteful the implementation can be when it's not MIT code. ;)
Indeed, if anyone ever does look at it, can I vote for including
the hooks f
21 matches
Mail list logo
