Amos,
Thanks.
I'll give it a try.
Gilboa
On Wed, 2005-08-31 at 08:40 +1000, Amos Shapira wrote:
Have you though of startting with the code of sendfile and going from
there to add the processing?
--Amos
On 8/30/05, Gilboa Davara [EMAIL PROTECTED] wrote:
On Tue, 2005-08-30 at 14:40
the sys_open() as was suggested in GergKH article I had
cited in
the thread from a month ago ? ( sys_open() accpets the O_DIRECT flag)
Regards,,
Rami
On 8/29/05, Gilboa Davara [EMAIL PROTECTED] wrote:
Hello all,
Couple of weeks ago I started a thread called File I/O
File I/O within kernel
threads? which ended with a call for numbers. (Read: Is I/O within
kernel performance increase justifies the development overhead?)
Last week I took my user-land simulator (that takes a file, reads it,
and creates and sends two raw multiplexed streams out
Gilboa Davara wrote:
Hello all,
Couple of weeks ago I started a thread called File I/O within kernel
threads? which ended with a call for numbers. (Read: Is I/O within
kernel performance increase justifies the development overhead?)
Last week I took my user-land simulator (that takes a file
On Tue, 30 Aug 2005, Gilboa Davara wrote:
Anyway, if you don't know how to use O_DIRECT from inside the kernel,
why don't you take a look at the part in teh kernel that implments
O_DIRECT from user space and do the same thing?
Already on it; However, this code is fairly complex. It
On Tue, 2005-08-30 at 14:40 +0300, guy keren wrote:
On Tue, 30 Aug 2005, Gilboa Davara wrote:
Anyway, if you don't know how to use O_DIRECT from inside the kernel,
why don't you take a look at the part in teh kernel that implments
O_DIRECT from user space and do the same thing?
Hi,
Maybe you should verify you don't have an alignment problem when using O_DIRECT.
When you try , from user space , to use O_DIRECT for reading
from a file, you must use page granularity for achieving page alignemnent.
according to the man (2) read , regarding O_DIRECT flag:
...
Transfer
Hello all,
Couple of weeks ago I started a thread called File I/O within kernel
threads? which ended with a call for numbers. (Read: Is I/O within
kernel performance increase justifies the development overhead?)
Last week I took my user-land simulator (that takes a file, reads it,
and creates
Gilboa Davara wrote:
Muli,
I well aware of the controversy surrounding FS access from kernel
modules and I accept, that in general, kernel modules should be using
the FS for storage.
However, in essence, I'm using the *wrong* tool for the right job: I
shouldn't be using Linux on a i386/x86-64
Umm...
Let me try and further explain what I need.
I'm writing a certain software network filter that handles -certain-
Ethernet and ATM/POS traffic.
Due to obvious performance consideration (Especially when under ATM) the
filter runs in kernel space, start to finish.
After the traffic is
Gilboa Davara wrote:
Umm...
As far as I can see, realyfs uses memory buffer for storage, which is
major no-no in my case:
At 50-200MB/sec I'll deplete the system RAM within minutes (even on
AMD64) and as far as I can see, there's no obvious way to commit the
buffers into static storage.
Current
Gilad Ben-Yossef wrote:
So long as you didn't perform 2, you want the information to wait in a
temporary buffer (I first wrote bugger here, which is rather funny ;-)
A Freudian slip is when you mean one thing but say your mother.
Now you can write that Temporary buffer layer in kernel that
Gilad,
Umm... Interesting. You might be right... but I'm still not convinced.
(Though my project manager will love the general idea. To say the least,
she doesn't really fancy the idea of writing our own FS :))
I'm sorry if I seound harsh, but I don't think you udnerstand your own
needs.
It
On Sun, Jul 31, 2005 at 04:53:21PM +0300, Shachar Shemesh wrote:
The RelayFS page talks about why they are not the same as netlink, but
they don't actually say what the difference is, or why they think it is
better. I'd love to hear why you recommend one but not the other - what
are the
Muli Ben-Yehuda wrote:
On Sun, Jul 31, 2005 at 04:53:21PM +0300, Shachar Shemesh wrote:
The RelayFS page talks about why they are not the same as netlink, but
they don't actually say what the difference is, or why they think it is
better. I'd love to hear why you recommend one but not the
Gilboa Davara wrote:
Let's try to analyze them together - you need to store large amount of
data from the network for proccessing by a further entity. What that
data is exactly doesn't matter, but we will note that you might need to
do non trivial handling of the data (encryption).
I
On Sun, Jul 31, 2005 at 05:31:11PM +0300, Shachar Shemesh wrote:
and a device+ioctl?
deprecated, except in very specific case (only one I can recall in
recent memory is the Cell's SPE interface, and that one is not yet
decided).
/sys?
Setting and reading device configuration and attributes.
Gilboa Davara wrote:
Here's how I see it:
Kernel 1:
Device - SKB - Reassembly - Disk.
(I can even save the third memcpy [Reassembly - Disk] I go rewrite the
world under me)
User:
Device - SKB - Reassembly ( - ?) Relayfs - User: write(2) -
Kernel: sys_write (copy_from_user) - Disk.
On Sun, 2005-07-31 at 17:35 +0300, Gilad Ben-Yossef wrote:
I should add the encryption optional, depending on load and source. (And
more important, how fanatical is the client)
(There's no way in hell, I'll be able to process and encrypt two OC48
links in real time...)
I believe
On Sun, 31 Jul 2005, Gilboa Davara wrote:
On Sun, 2005-07-31 at 17:35 +0300, Gilad Ben-Yossef wrote:
Interesting... that might work.
Let me first point out that once the cells/frames have been processed, I
don't care much for timing. (Which bodes well on your solution).
However,
On 8/1/05, Gilboa Davara [EMAIL PROTECTED] wrote:
To be honest, I don't worry much about encryption. I doubt that it'll be
used in any real high-bandwidth case. It will be used in cases where
security matters most and bandwidth is *very* low to begin with.
Use an encrypted filesystem?
And as
: Gilboa Davara [EMAIL PROTECTED]
To: IL List linux-il@linux.org.il
Subject: Re: File I/O within kernel threads?
Date: Thu, 28 Jul 2005 17:24:41 +0300
Gilad,
First, thanks for the answer.
On Thu, 2005-07-28 at 16:44 +0300, Gilad Ben-Yossef wrote:
A kernel thread is indeed proccess
Muli,
I well aware of the controversy surrounding FS access from kernel
modules and I accept, that in general, kernel modules should be using
the FS for storage.
However, in essence, I'm using the *wrong* tool for the right job: I
shouldn't be using Linux on a i386/x86-64 in the first place; I
Muli,
I well aware of the controversy surrounding FS access from kernel
modules and I accept, that in general, kernel modules should be using
the FS for storage.
However, in essence, I'm using the *wrong* tool for the right job: I
shouldn't be using Linux on a i386/x86-64 in the first place; I
On Sat, 30 Jul 2005, Gilboa Davara wrote:
After doing some contemplating I decided that I don't really need access
to an FS; or actually,all I need a is huge cyclic buffer with fast
sequential R/W and force-able sync. If anything the VFS layer will only
slow me down.
I wonder if the raw
On Sat, Jul 30, 2005 at 09:50:29AM +0300, Gilboa Davara wrote:
After doing some contemplating I decided that I don't really need access
to an FS; or actually, all I need a is huge cyclic buffer with fast
sequential R/W and force-able sync. If anything the VFS layer will only
slow me down.
I/O within kernel threads?
Date: Thu, 28 Jul 2005 17:24:41 +0300
Gilad,
First, thanks for the answer.
On Thu, 2005-07-28 at 16:44 +0300, Gilad Ben-Yossef wrote:
A kernel thread is indeed proccess context, but since you brought it
up
already and assuming we're talking 2.6, the correct way to do
Being an idiot is fun.
kthread *is* a process context.
Never the less, if anyone has interesting insight as for how to .very.
fast file I/O inside the kernel (Yes, I know that its considered bad,
and may results from a bad design decision; Linux was never designed
that way, etc. Umm... sadly (?)
Gilboa Davara wrote:
I need to file I/O operations from within kthread context (Multiple fast
network streams, no time to push it upwards into user-space)
As far as I remember, flip_open/close and -read/-write fs methods must
be called from a process context.
While I can move the I/O task
Gilad,
First, thanks for the answer.
On Thu, 2005-07-28 at 16:44 +0300, Gilad Ben-Yossef wrote:
A kernel thread is indeed proccess context, but since you brought it
up
already and assuming we're talking 2.6, the correct way to do is
use
work queues (and hence schedule_work) instead of
On Thu, Jul 28, 2005 at 04:15:57PM +0300, Gilboa Davara wrote:
Never the less, if anyone has interesting insight as for how to .very.
fast file I/O inside the kernel (Yes, I know that its considered bad,
and may results from a bad design decision; Linux was never designed
that way, etc.
31 matches
Mail list logo
