Date: Tue, 16 Sep 1997 01:06:56 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: Julian Elischer <julian@whistle.com> Cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Fast Encryption (in kernel) seeked Message-ID: <XFMail.970916010656.Shimon@i-Connect.Net> In-Reply-To: <Pine.BSF.3.95.970916003201.13496B-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Julian Elischer; On 16-Sep-97 you wrote:
> To answer this question correctly,
> We need to know more details..
Gladly :-)
> every algorythm has its day. It depends on what the situation is.
>
> For example, if there will be less than 100 of these 'pointers'
> outstanding at a time, different schemes would be used to the case where
> there are 100000 outstanding..
Oh, somewhere in between. A busy system may hold about 10,000 outstanding
tickets.
> can you guarentee that each pointer given out will be 'returned'?
Not at all. I can guarantee that until it is returned, the pointer will be
dormant.
> will it be returned only once?
Yup.
> what if a process dies while owning a pointer?
Then eventually the pointer goes away.
> when does the buffer become free?
very soon after the pointer comes back home.
> who allocates the buffers?
malloc.
> I have code that does all this but it's only useful to you if
> what you want to do matches the goals of what I was designing for..
>
> tell me more..
This is part of the DLM. When a remote request comes in, we allocate a
bucket (structure) to hold the remote request, send it up to a userspace
daemon. The daemon resolves the target where the lock should be applied,
sends a packet to that host, gets the result and puts is back to the kernel.
The kernel gets the bucket, extracts from it the pointer, identifies who is
sleeping, waiting for the request to be resoved, wakes it out. The process
that slept wakes up and continues processing.
Two points:
a. This is a very inaccurate description of the remote leg in a shared lock
processing. It is accurate enough to give you the background, though.
b. I do NOT want this brief to be construed as a presentation of or
introduction to the DLM. This will come soon enough.
I want to guarantee that the cookie the kernel requestor sleeps on is
unique within the kernel address space and genuine. To do so, I need to:
a. Validate that it is genuine.
b. Find, QUICKLY, the original bucket that holds the request; this is
where the request and all its atndant pieces are.
---
Sincerely Yours, (Sent on 16-Sep-97, 00:53:14
by XF-Mail)
Simon Shapiro Atlas Telecom
Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005
Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970916010656.Shimon>