Hi,
On Fri, Sep 01, 2000 at 01:30:26PM +0300, Matti Aarnio wrote:
>
> Stephen, could you have a moment to look at the struct buffer_head {}
> alignment matters ? And possible configure time change to make the
> block number possibly a 'long long' variable ?
> Changeing field order
Hi,
On Fri, Sep 01, 2000 at 12:09:23AM -0700, Linda Walsh wrote:
> Perhaps an "easy" way to go would be to convert block numbers to
> type "block_nr_t", then one could measure the difference that 10's of
> nanoseconds make against seeks and reads of disk data.
You might not find it just
Hi,
On Sun, Sep 03, 2000 at 11:36:25PM +0200, Andrea Ferraris wrote:
I used to think that. Im planning on deploying a 1Tb IDE raid using 3ware
kit for an ftp site very soon. Its very cheap and its very fast. UDMA
with
one disk per channel and the controller doing some of the work.
Hi,
On Sat, Sep 02, 2000 at 09:41:03PM +0200, Ingo Molnar wrote:
On Sat, 2 Sep 2000, Alexander Viro wrote:
unlink() and the last munmap()/exit() will get rid of it...
yep - and this isnt possible with traditional SysV shared memory, and isnt
possible with traditional SysV semaphores.
Hi,
On Sun, Sep 03, 2000 at 07:29:56PM +0200, Ingo Molnar wrote:
On Sun, 3 Sep 2000, Andi Kleen wrote:
I did the same for fragment RX some months ago (simple fragment lists
that were copy-checksummed to user space). Overall it is probably
better to use a kiovec, because that can be
Hi Ted,
To be fixed for 2.4:
1) Non-atomic pte updates
The page aging code and mprotect both modify existing ptes
non-atomically. That can stomp on the VM hardware on other CPUs
setting the dirty bit on mmaped pages when using threads. 2.2 is
vulnerable too.
2) RSS locking
Hi,
On Mon, Sep 04, 2000 at 11:29:56PM +0200, Rasmus Andersen wrote:
I have changed the interface to mark_buffer_dirty (as per Tigran
Aivazian's suggestion). This impacts a lot of places in the kernel
(trivially), noticeably the file systems. The URL below points a
big patch for all
Hi,
On Thu, Aug 31, 2000 at 01:42:28PM -0600, Evan Jones wrote:
>
> I hope this has not been discussed before. I think I have searched the
> archive fairly exhaustively. This issue may also no longer exist on the
> 2.4 kernel series because I have not tested it on that kernel.
>
> I have
Hi,
On Sat, Sep 02, 2000 at 11:50:32AM -0700, [EMAIL PROTECTED] wrote:
> The kernel is compiled with the 4GB option. (which I think is
> the 2/2GB option from 2.2.x kernels). I believe the option is
> supposed to assign 2GB of address space to real memory, and
> 2GB to virtual memory (from a
601 - 609 of 609 matches
Mail list logo
