lkml.org 
[lkml]   [2005]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][FAT] FAT dirent scan with hin take #3
Machida, Hiroyuki wrote:
> OGAWA Hirofumi wrote:
>
>> "Machida, Hiroyuki" <machida@sm.sony.co.jp> writes:
>>
>>
>>> Right, it looks like TLB, which holds cache "Physical addres"
>>> correponding to "Logical address". In this case, PID and file name
>>> to be looked up, perform role of "Logical address".
>>
>>
>>
>> But, there is the big difference between hint table and TLB. TLB is
>> just the cache, and TLB hit is perfectly good, because kernel is
>> flushing the wrong values.
>>
>> But this hint table is just collecting the recent access, it's not
>> cache, and it's not tracking the process's access at all. So, since
>> the hint value is really random, the hint value may be bad.
>>
>> I worry bad cases of this.
>>
>>
>> Umm... How about tracking the access pattern of process? If that
>> seems randomly access, just give up tracking and return no hint. And,
>> probably, I think it would be easy to improve the behavior later.
>>
>> What do you think?
>
>
> Sounds interesting...
>
> Once concern about global URL in general, it tends to be occupied
^^^
sorry, LRU not URL.

> by specific pattern, like accesses from one process or to on dir.
one dir.

> It prevents to realize locality.
>
> I think it's better to have limitations like;
> entries for same process would be limited to 2/3
> entries for same dir would be limited to 1/3
>
>
>> e.g.
>>
>> #define FAT_LOOKUP_HINT_MAX 16
>>
>> /* this data per task */
>> struct fat_lookup_hint {
>> struct list_head lru;
>> pid_t pid;
>> struct super_block *sb;
>> struct inode *dir;
>> loff_t last_pos;
>> /* int state;*/
>> };
>
>
> Does this mean for each process recording last recent 16
> accesses to FAT file system ? If true, pid would be eliminated.
>
> I guess it's better to record nr_slots for this entry.
>
> As implementation issue, if number of entires is small enough,
> we can use an array, not a list.
>
>
>> static void fat_lkup_hint_inval(struct super_block *, struct inode *);
>> static loff_t fat_lkup_hint_get(struct super_block *, struct inode *);
>> static void fat_lkup_hint_add(struct super_block *, struct inode *,
>> loff_t);
>> static int fat_lkup_hint_init(void);
>
>
> I think super_block can be retrieved from inode, any other intention do
> you have?
>
>
> In addtion, we can do follwoing to check the exact match case;
>
> 0. Record hash value of file name in struct fat_lookup_hint
>
> 1. Check hash value to find exact match case,
> 1-1. If matched entry is found, check if file name and
> file name retieved from dirent corresponding
> 1-2. We found the entry
>
> 2. Get hint value, if there seem to have locality
> 2-1. Check locality of access pattern for this PID and this
> DIR.
> 2-2. If we relize access locality, return hit value so that
> it covers a potential working set.
> 2-3. Use hint value as start position of dirscan.
>


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

\
 
 \ /
  Last update: 2005-09-01 09:49    [W:0.103 / U:1.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site