Re: Scaling problem with shmem_sb_info->stat_lock

[William Lee Irwin III <wli@holomorphy.com>]

On Wed, 28 Jul 2004, William Lee Irwin III wrote:
>> For the general case it may still make sense to do this. SGI will have
>> to comment here, as the workloads I'm involved with are kernel intensive
>> enough in other areas and generally run on small enough systems to have
>> no visible issues in or around the areas described.

On Wed, Jul 28, 2004 at 05:21:58PM -0500, Brent Casavant wrote:
> With Hugh's fix, the problem has now moved to other areas -- I consider
> the stat_lock issue solved.  Now I'm running up against the shmem_inode_info
> lock field.  A per-CPU structure isn't appropriate here because what it's
> mostly protecting is the inode swap entries, and that isn't at all amenable
> to a per-CPU breakdown (i.e. this is real data, not statistics).

This does look like it needs ad hoc methods for each of the various
fields.


On Wed, Jul 28, 2004 at 05:21:58PM -0500, Brent Casavant wrote:
> The "obvious" fix is to morph the code so that the swap entries can be
> updated in parallel to eachother and in parallel to the other miscellaneous
> fields in the shmem_inode_info structure.  But this would be one *nasty*
> piece of work to accomplish, much less accomplish cleanly and correctly.
> I'm pretty sure my Linux skillset isn't up to the task, though it hasn't
> kept me from trying.  On the upside I don't think it would significantly
> impact performance on low processor-count systems, if we can manage to
> do it at all.
> I'm kind of hoping for a fairy godmother to drop in, wave her magic wand,
> and say "Here's the quick and easy and obviously correct solution".  But
> what're the chances of that :).

This may actually have some positive impact on highly kernel-intensive
low processor count database workloads (where kernel intensiveness makes
up for the reduced processor count vs. the usual numerical applications
at high processor counts on SGI systems). At the moment a number of
stability issues have piled up that I need to take care of, but I would
be happy to work with you on devising methods of addressing this when
those clear up, which should be by the end of this week.


-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>