RE: why swap at all?

[Buddy Lumpkin]

>I can picture it but I don't know how the kernel is going to handle
>it. All I am doing is speaking from what I have seen.

>http://marc.theaimsgroup.com/?l=linux-kernel&m=107817776322044&w=2

>This post for example, has profiles of a 32 CPU system with 16 FC
>controllers and over 1000 disks, doing some database workload. Does
>this qualify as big iron?

>In the bottom profile, you see the disks being kept busy with 50%
>idle time. The top 6 functions are all to do with generating IO
>requests and pushing them through the block layer, none of them
>involve memory reclaim.


They are using direct I/O ... therefore the DMA memory transfers are mapped
directly into the user address space bypassing the pagecache altogether.

--Buddy




There are profiles from a different setup in a related thread here:

http://groups.google.com.au/groups?q=g:thl3816668183d&dq=&hl=en&lr=&ie=UTF-8
&selm=1yjKu-7qU-1%40gated-at.bofh.it&rnum=9

I think we see kmem_cache_alloc make a miserable showing for the
memory allocation team, but it wouldn't even be there if the
profile were sorted by ticks (the left hand column).


Now If you had some experiences of memory reclaim slowing down
block IO, I'd love to hear them because that is related to an area
that I am looking at currently. I'm not saying what you claim is
impossible, but it is something that shouldn't happen and we don't
relly see... You're continuing to insist there is a problem but
that simply isn't helpful without further details.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/