There's a fundamental issue here that I don't quite get: if we're in
rendezvous mode, why is there data on the wire if we aren't ready to
receive it? The whole point of rendezvous mode is to *not* send the data
until the matching receive has been posted.
What am I missing?
Thanks,
Rob
Phil
Ok, I think I _might_ see what the problem is with the BMI messaging.
I haven't 100% confirmed yet, but it looks like we have the following
scenario:
On the client side:
- pvfs2-client-core starts a I/O operation (write) to server X
- a send (for the request) is posted,
Hi Julian,
Thanks for sending out your thoughts and ideas. Even though we've
talked about most of this offline, I'm just going to summarize what I
said in case others want to comment.
-sam
On Jun 10, 2006, at 1:57 PM, Julian Martin Kunkel wrote:
Hi,
I looked a bit arround the implement
Oh ok. Thanks for the info, Rob.
Murali
On Tue, 13 Jun 2006, Rob Ross wrote:
> hey,
>
> that's an open topic i think. keep in mind that we're actively trying to
> avoid the kernel in some systems (e.g. BG/*)...
>
> rob
>
> Murali Vilayannur wrote:
> > Hi guys,
> > Is this the general direction fo
hey,
that's an open topic i think. keep in mind that we're actively trying to
avoid the kernel in some systems (e.g. BG/*)...
rob
Murali Vilayannur wrote:
Hi guys,
Is this the general direction for caching in PVFS2? A user-space cache
which is timeout-based rather than completely coherent ma
Hi guys,
Is this the general direction for caching in PVFS2? A user-space cache
which is timeout-based rather than completely coherent may as well be kept
inside the kernel module, no? :)
Sorry if I am stirring up a hornet's nest or if this was discussed
before...
Thanks,
Murali
> Sorry about tha
Hi Murali,
I'm not seeing any problems with the dd scenario that you describe (I
tried running 8-10 of them simultaneously), but I may just have
different timing characteristics.
One thing that I neglected to mention about the application that I am
running is that it actually has 2 processes
I reverted my src/io/bmi directory back to a snapshot of what was in CVS
around March, but I still have the same problems. It doesn't seem to be
impacted by the pipe changes or the socket buffer size changes.
I haven't tried your dd test case yet, but I will give that a shot soon.
-Phil
Mura
Hi Phil,
Thanks for sending this patch. Naming consistency is always
appreciated. Committed to trunk.
-sam
On Jun 7, 2006, at 11:07 AM, Phil Carns wrote:
tcache-terminology.patch:
--
This patch clarifies/fixes some terminology disagreement between
the tcache documentat
On Jun 13, 2006, at 9:14 AM, Rob Ross wrote:
Sam Lang wrote:
On Jun 12, 2006, at 10:07 PM, Rob Ross wrote:
i know we're trying to keep the # of DBs down, but would it
really hurt that much to just use a separate DB for this data
rather than having to play funny games with the key strings?
Sam Lang wrote:
On Jun 12, 2006, at 10:07 PM, Rob Ross wrote:
i know we're trying to keep the # of DBs down, but would it really
hurt that much to just use a separate DB for this data rather than
having to play funny games with the key strings?
I don't have much preference either way. I do
On Jun 12, 2006, at 10:07 PM, Rob Ross wrote:
hey,
i know we're trying to keep the # of DBs down, but would it really
hurt that much to just use a separate DB for this data rather than
having to play funny games with the key strings?
I don't have much preference either way. I don't find
12 matches
Mail list logo
