[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXbPWsgaZmsvHZGEX-CxB579tG+zusXiYhR-13RcEnGvQ@mail.gmail.com>
Date: Wed, 19 Oct 2011 17:39:37 -0700
From: Andy Lutomirski <luto@...capital.net>
To: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-ext4@...r.kernel.org
Subject: Latency writing to an mlocked ext4 mapping
I have a real-time program that has everything mlocked (i.e.
mlockall(MCL_CURRENT | MCL_FUTURE)). It has some log files opened for
writing. Those files are opened and memset to zero in another thread
to fault everything in. The system is under light I/O load with very
little memory pressure.
Latencytop shows frequent latency in the real-time threads. The main
offenders are:
schedule sleep_on_page wait_on_page_bit ext4_page_mkwrite do_wp_page
handle_pte_fault handle_mm_fault do_page_fault page_fault
schedule do_get_write_access jbd2_journal_get_write_access
__ext4_journal_get_write_access ext4_reserve_inode_write
ext4_mark_inode_dirty ext4_dirty_inode __mark_inode_dirty
file_update_time do_wp_page handle_pte_fault handle_mm_fault
I imagine the problem is that the system is periodically writing out
my dirty pages and marking them clean (and hence write protected).
When I try to write to them, the kernel makes them writable again,
which causes latency either due to updating the inode mtime or because
the file is being written to disk when I try to write to it.
Is there any way to prevent this? One possibility would be a way to
ask the kernel not to write the file out to disk. Another would be a
way to ask the kernel to make a copy of the file when it writes it
disk and leave the original mapping writable.
Obviously I can fix this by mapping anonymous memory, but then I need
another thread to periodically write my logs out to disk, and if that
crashes, I lose data.
--
Andy Lutomirski
AMA Capital Management, LLC
Office: (310) 553-5322
Mobile: (650) 906-0647
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists