Re: Why don't we make mmap MAP_SHARED with /dev/zero possible?

Ingo Molnar
1999-11-03T16:46:59Z

On 3 Nov 1999, Eric W. Biederman wrote:

> Not really. I played with the idea, and the only really tricky aspect I saw
> was how to write a version of copy_to/from_user that would handle the bigmem
> case. Because kmap ... copy .. kunmap isn't safe as you can sleep due
> to a page fault.

yes, i implemented a new 'kaddr = kmap_permanent(page)'
'kunmap_permanent(kaddr)' interface which is schedulable. This is now
getting used in exec.c (argument pages can be significantly big) and the
page cache.

> And I played with putting a wrapper around ll_rw_block calls in
> buffer.c that would allocate bounce buffers from the buffer cache as
> needed.

that is a much more problematic issue, especially if you consider future
64-bit PCI DMAing. What i did was to change bh->b_data to bh->b_page,
which b_page is a 32-bit value describing the physical address of the
buffer, in 512-byte units. This also ment changing bazillion places where
b_data was used (lowlevel fs, buffer-cache and block layer, device
drivers) ... But it's working just fine on my box:

moon:~> cat /proc/meminfo

MemTotal: 8249708 kB
MemFree: 7760256 kB
MemShared: 0 kB
Buffers: 20292 kB
Cached: 432052 kB <=== 432M pagecache
HighTotal: 7471104 kB
HighFree: 7035928 kB <=== 444M high memory allocated
LowTotal: 778604 kB
LowFree: 724328 kB <=== 50M normal memory allocated
SwapTotal: 0 kB
SwapFree: 0 kB

> I'll probably get back to shmfs in a kernel version or two.

looking forward to test it, i believe we could get some spectacular
benchmark numbers with that thing and 2.4 ...

-- mingo