* Dave Hansen ([EMAIL PROTECTED]) wrote:
> On Fri, 2007-11-30 at 11:11 -0500, Mathieu Desnoyers wrote:
> > +static inline swp_entry_t page_swp_entry(struct page *page)
> > +{
> > + swp_entry_t entry;
> > + VM_BUG_ON(!PageSwapCache(page));
> > + entry.val = page_private(page);
> > + return entry;
> > +}
>
> This probably needs to be introduced (and used) in a separate patch.
> Please fix up those other places in the code that can take advantage of
> it.
>
Sure,
> > #ifdef CONFIG_MIGRATION
> > static inline swp_entry_t make_migration_entry(struct page *page, int
> > write)
> > {
> > Index: linux-2.6-lttng/mm/swapfile.c
> > ===================================================================
> > --- linux-2.6-lttng.orig/mm/swapfile.c 2007-11-30 09:18:38.000000000
> > -0500
> > +++ linux-2.6-lttng/mm/swapfile.c 2007-11-30 10:21:50.000000000
> > -0500
> > @@ -1279,6 +1279,7 @@ asmlinkage long sys_swapoff(const char _
> > swap_map = p->swap_map;
> > p->swap_map = NULL;
> > p->flags = 0;
> > + trace_mark(mm_swap_file_close, "filp %p", swap_file);
> > spin_unlock(&swap_lock);
> > mutex_unlock(&swapon_mutex);
> > vfree(swap_map);
> > @@ -1660,6 +1661,8 @@ asmlinkage long sys_swapon(const char __
> > } else {
> > swap_info[prev].next = p - swap_info;
> > }
> > + trace_mark(mm_swap_file_open, "filp %p filename %s",
> > + swap_file, name);
>
> You print out the filp a number of times here, but how does that help in
> a trace? If I was trying to figure out which swapfile, I'd probably
> just want to know the swp_entry_t->type, then I could look at this:
>
> [EMAIL PROTECTED]:~/garbage$ cat /proc/swaps
> Filename Type Size Used
> Priority
> /dev/sda2 partition 1992052 649336 -1
>
> to see the ordering.
>
Given a trace including :
- Swapfiles initially used
- multiple swapon/swapoff
- swap in/out events
We would like to be able to tell which swap file the information has
been written to/read from at any given time during the trace.
Therefore, I dump the swap file information at the beginning of the
trace (see the ltt_dump_swap_files function) and also follow each
swapon/swapoff.
The minimal information that has to be saved at each swap read/write
seems to be the struct file * that is used by the operation. We can then
map back to the file used by knowing the mapping between struct file *
and associated file names (dump/swapon/swapoff instrumentation).
The swp_entry_t->type does not seem to map to any specific information
in /proc/swaps ? (or I may have missed a detail) Even if it does, it is
limited to a specific point in time and does not follow swapon/swapoff
events.
You are talking about ordering in /proc/swaps : I wonder what happens if
we add/remove swap files from the array : I guess the swp_entry_t
ordering may become mixed up with the order of the /proc/swaps output,
since it is based on the swap_info array which will fill empty spots
upon swapon (again, unless I missed a clever detail).
Mathieu
> -- Dave
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
