Re: continuous write to hard disk
phil-news-nospam_at_ipal.net
Date: 03/08/05
- Next message: Peter T. Breuer: "Re: ioctl() for dummies"
- Previous message: Floyd L. Davidson: "Re: ioctl() for dummies"
- In reply to: Jan Kandziora: "Re: continuous write to hard disk"
- Next in thread: Nix: "Re: continuous write to hard disk"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 8 Mar 2005 21:11:55 GMT
On Mon, 07 Mar 2005 10:35:29 +0100 Jan Kandziora <jjj@gmx.de> wrote:
| phil-news-nospam@ipal.net schrieb:
|> | You can easily come around any scheduling latency if you use static
|> | priorities (SCHED_FIFO). In that case, the is no "thundering herd" of
|> | processes the scheduler has to consider to wake up. With the O(1)
|> | scheduler and only one process per priority, things should be really
|> | fast.
|>
|> It's not a process competition issue as far as I can tell. It's just the
|> latency of getting that one process dispatched and it running around the
|> loop to get another write() started.
|>
| No, No, I didn't mean it that way.
| If you have several processes with the same priority, the kernel has to wake
| up *all* of them, and the ones which can't yet work because their I/O
| hasn't been completed yet are going to sleep again. That's the "thundering
| herd" problem and the only cause for scheduling latency with the O(1)
| scheduler. Assigning a static priority solves that - but has other
| problems, sure.
Why would other processes wake up? They would have other kinds of sleep
or block criteria. If some other process is waiting for a child, why would
the kernel wake it up just because it happened to be at the same priority
level?
| Now I have understood your whole concept. But I don't think I will improve
| performance, as only one process may run at a time on a uniprocessor
| machine. You will have the same scheduling latency with the signal or
| ptrace() or anything else that you got with the blocking write().
Maybe you still don't understand. I'm not trying to _run_ two processes
at the same time ... I'm trying to have two processes blocked in write()
at the same time. Properly coordinated, the 2nd process would not run
(or be runnable) at the same time, anyway. The condition I am trying to
have is process B blocked doing the first write() and process C blocked
trying to do the second write(). It goes like this:
Parent sets up some shared memory.
Parent sets up pipes and forks child B.
Parent sets up pipes and forks child C.
Child B blocks in read() on pipe for message from parent.
Child C blocks in read() on pipe for message from parent.
Parent reads or generates 1st data and places it in shared memory.
Parent writes to pipe B with shared memory location.
Child B receives message and write()'s data.
Parent reads or generates 2nd data and places it in shared memory.
Parent notices (how, to be determined) child B has started write().
Parent writes to pipe C with shared memory location for 2nd data.
Child C receives message and write()'s data.
Parent reads or generates 3rd data and places it in shared memory.
Parent waits.
Device finishes 1st write().
Kernel starts device on 2nd write() (that child C has already issued).
Child B returns from write() with success status.
Child B signals parent OK.
Child B blocks in read() on pipe for message from parent.
Parent writes to pipe B with shared memory location for 3rd data.
Child B receives message and write()'s 3rd data.
... and so on.
The purpose is not to have two processes running. Instead, two processes
is a means to have a 2nd data buffer "waiting in the wings" in the kernel
that otherwise could not happen because a single process will get blocked
doing the 1st write().
|> | But that won't help much, I think. There can only be a limited number
|> | (one?) DMA transfer be in progress for a host adapter. Though the
|> | processor may do something useful in that time, it has no chance to
|> | start another DMA transfer which would not block immediately. You would
|> | only get the short amount of time then scheduler needs to unblock the
|> | first process. But then again, the second process has to be unblocked,
|> | too, and I don't see how there is a difference in the time needed by the
|> | two possibilities.
|>
|> But the idea is to have a request already pending so the kernel can start
|> the write immediately. Whether that is all done in 1 process or 2
|> processes
|> depends on what mechanisms are available. There does not appear to be any
|> means to do this with 1 process right now. And even with 2 it isn't easy
|> (have to use ptrace).
|>
| The original idea was to get around scheduling latencies with one process,
| if I understood correctly. These latencies originating from the processor
| doing something in kernel mode -> during that time, the processor can't do
| anything in user mode or anything else in kernel mode -> your second
| process has to wait, too.
I don't know that there is any scheduling latency. Maybe there is, or maybe
not. But there is an overall latency, even if some of that is in the process
itself. It's just the time from hardware interrupt from the device to the
next device command to write that I am trying to minimize. If another data
buffer is in the queue, it can go now.
| For a multiprocessor system, your considerations are perfectly
| understandable. For a uniprocessor system, however, they make very little
| sense. Got my idea?
We are not in sync on ideas here. I'm not trying to make use of two CPUs
at the same time. The way I propose does not need for the 2nd process to
use any CPU time until after the 1st process has blocked. Then while that
1st data is writing and the 1st process is blocked, then the 2nd process
can run. The parent would coordinate it, and there is no need to literally
run both at the same time. The idea isn't to have the ability to do two
CPU instructions concurrently ... the idea is to be able to do a 2nd write()
despite the 1st write() causing the process that does so to be blocked.
A 2nd CPU would be of no value because it can all be done on one CPU.
-- ----------------------------------------------------------------------------- | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | -----------------------------------------------------------------------------
- Next message: Peter T. Breuer: "Re: ioctl() for dummies"
- Previous message: Floyd L. Davidson: "Re: ioctl() for dummies"
- In reply to: Jan Kandziora: "Re: continuous write to hard disk"
- Next in thread: Nix: "Re: continuous write to hard disk"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
