[parisc-linux] 2.4.0-test6 lack of speed
Richard Hirst
rhirst@linuxcare.com
Wed, 30 Aug 2000 11:15:23 +0100
On Tue, Aug 29, 2000 at 05:23:08PM -0400, Matthew Wilcox wrote:
> My attempt at fixing this in a sane manner led me to create:
>
> #define user_fdc(addr) asm volatile("fdc 0(%%sr3,%0)" : : "r" (addr))
> (...)
>
> and
>
> #define kernel_fdc(addr) asm volatile("fdc 0(%%sr0,%0)" : : "r" (addr))
> (...)
>
> however, the resulting kernel wouldn't boot. So let's take this a
I tried something similar, with the same result.
What do you make of arch/parisc/lib/usercopy.c
unsigned long
__generic_copy_to_user(void *to, const void *from, unsigned long n)
{
if (access_ok(VERIFY_WRITE, to, n)) {
__flush_dcache_range((unsigned long)from, n);
lcopy_to_user(to,from,n);
__flush_dcache_range((unsigned long)to, n);
}
return 0;
}
Typically 'from' would be a kernel virtual address, and 'to' would
be a user virtual address, yes? So, that is expecting __flush_dcache_range()
to know which space register to use. But then sometimes these functions
for accessing user space are redirected at kernel space by set_fs().
In that case both addresses are kernel virtual addresses.
lcopy_to_user() claims to modify %sr1 to get the right space in %sr1,
based on a flag in the task struct.
See copy_strings_kernel() in fs/exec.c for an example of where
copy_from_user( is used to copy from kernel space.
Richard