Hi all.
In current git (and for a while now), an attempt to allocate memory with
GFP_ATOMIC will fail if we're below the low watermark level. The only way to
access that memory that I can see (not that I've looked that hard) is to have
PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is correct.
Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about GFP_KERNEL?
The following patch is a potential fix for GFP_ATOMIC.
Regards,
Nigel
Signed-off-by: Nigel Cunningham <[email protected]>
page_alloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -ruNp 995-gfp-atomic-alloc.patch-old/mm/page_alloc.c 995-gfp-atomic-alloc.patch-new/mm/page_alloc.c
--- 995-gfp-atomic-alloc.patch-old/mm/page_alloc.c 2007-08-20 11:14:34.000000000 +1000
+++ 995-gfp-atomic-alloc.patch-new/mm/page_alloc.c 2007-08-20 11:11:09.000000000 +1000
@@ -1286,8 +1286,8 @@ restart:
/* This allocation should allow future memory freeing. */
rebalance:
- if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
- && !in_interrupt()) {
+ if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)) ||
+ (gfp_mask & GFP_ATOMIC)) && !in_interrupt()) {
if (!(gfp_mask & __GFP_NOMEMALLOC)) {
nofail_alloc:
/* go through the zonelist yet again, ignoring mins */
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> Hi all.
>
> In current git (and for a while now), an attempt to allocate memory with
> GFP_ATOMIC will fail if we're below the low watermark level. The only way to
> access that memory that I can see (not that I've looked that hard) is to have
> PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is correct.
> Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about GFP_KERNEL?
>
> The following patch is a potential fix for GFP_ATOMIC.
Sorry, no.
GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
and hence can sleep and wait for reclaim so that should not be a problem
(usually).
GFP_ATOMIC may not access the reserves because the reserves are needed
to get out of OOM deadlocks within the VM. Consider the fact that
freeing memory needs memory - if there is no memory free, you cannot
free memory and you're pretty much stuck.
Hi.
On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > Hi all.
> >
> > In current git (and for a while now), an attempt to allocate memory with
> > GFP_ATOMIC will fail if we're below the low watermark level. The only way
to
> > access that memory that I can see (not that I've looked that hard) is to
have
> > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is
correct.
> > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about
GFP_KERNEL?
> >
> > The following patch is a potential fix for GFP_ATOMIC.
>
> Sorry, no.
>
> GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> and hence can sleep and wait for reclaim so that should not be a problem
> (usually).
>
> GFP_ATOMIC may not access the reserves because the reserves are needed
> to get out of OOM deadlocks within the VM. Consider the fact that
> freeing memory needs memory - if there is no memory free, you cannot
> free memory and you're pretty much stuck.
I guess, then, the question should be whether the watermark values are
appropriate. Do we need high order allocations watermarked if this is the
only purpose, particularly considering that whatever memory is allocated for
this purpose is essentially useless 99.9% of the time?
Regards,
Nigel
--
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.
On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> Hi.
>
> On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > Hi all.
> > >
> > > In current git (and for a while now), an attempt to allocate memory with
> > > GFP_ATOMIC will fail if we're below the low watermark level. The only way
> to
> > > access that memory that I can see (not that I've looked that hard) is to
> have
> > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is
> correct.
> > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about
> GFP_KERNEL?
> > >
> > > The following patch is a potential fix for GFP_ATOMIC.
> >
> > Sorry, no.
> >
> > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > and hence can sleep and wait for reclaim so that should not be a problem
> > (usually).
> >
> > GFP_ATOMIC may not access the reserves because the reserves are needed
> > to get out of OOM deadlocks within the VM. Consider the fact that
> > freeing memory needs memory - if there is no memory free, you cannot
> > free memory and you're pretty much stuck.
>
> I guess, then, the question should be whether the watermark values are
> appropriate. Do we need high order allocations watermarked if this is the
> only purpose, particularly considering that whatever memory is allocated for
> this purpose is essentially useless 99.9% of the time?
Could you perhaps explain what you're trying to do? No matter what we
do, GFP_ATOMIC will fail eventually, there is only so much one can do
without blocking.
As for higher order allocations, until we have a full online defrag
solution those too can fail at any moment (even with __GFP_WAIT).
Hi.
On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > Hi all.
> > > >
> > > > In current git (and for a while now), an attempt to allocate memory
with
> > > > GFP_ATOMIC will fail if we're below the low watermark level. The only
way
> > to
> > > > access that memory that I can see (not that I've looked that hard) is
to
> > have
> > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is
> > correct.
> > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about
> > GFP_KERNEL?
> > > >
> > > > The following patch is a potential fix for GFP_ATOMIC.
> > >
> > > Sorry, no.
> > >
> > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > and hence can sleep and wait for reclaim so that should not be a problem
> > > (usually).
> > >
> > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > freeing memory needs memory - if there is no memory free, you cannot
> > > free memory and you're pretty much stuck.
> >
> > I guess, then, the question should be whether the watermark values are
> > appropriate. Do we need high order allocations watermarked if this is the
> > only purpose, particularly considering that whatever memory is allocated
for
> > this purpose is essentially useless 99.9% of the time?
>
> Could you perhaps explain what you're trying to do? No matter what we
> do, GFP_ATOMIC will fail eventually, there is only so much one can do
> without blocking.
>
> As for higher order allocations, until we have a full online defrag
> solution those too can fail at any moment (even with __GFP_WAIT).
I was just trying to make hibernation more reliable in sitations where there's
low amounts of memory available. I guess the amount of memory that's reserved
for this has increased, because some users have been reporting issues that
hadn't appeared before. No problem. I'll work around it.
Nigel
--
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
On Mon, 2007-08-20 at 20:55 +1000, Nigel Cunningham wrote:
> Hi.
>
> On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > Hi.
> > >
> > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > Hi all.
> > > > >
> > > > > In current git (and for a while now), an attempt to allocate memory
> with
> > > > > GFP_ATOMIC will fail if we're below the low watermark level. The only
> way
> > > to
> > > > > access that memory that I can see (not that I've looked that hard) is
> to
> > > have
> > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is
> > > correct.
> > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about
> > > GFP_KERNEL?
> > > > >
> > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > >
> > > > Sorry, no.
> > > >
> > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > > and hence can sleep and wait for reclaim so that should not be a problem
> > > > (usually).
> > > >
> > > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > free memory and you're pretty much stuck.
> > >
> > > I guess, then, the question should be whether the watermark values are
> > > appropriate. Do we need high order allocations watermarked if this is the
> > > only purpose, particularly considering that whatever memory is allocated
> for
> > > this purpose is essentially useless 99.9% of the time?
> >
> > Could you perhaps explain what you're trying to do? No matter what we
> > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > without blocking.
> >
> > As for higher order allocations, until we have a full online defrag
> > solution those too can fail at any moment (even with __GFP_WAIT).
>
> I was just trying to make hibernation more reliable in sitations where there's
> low amounts of memory available. I guess the amount of memory that's reserved
> for this has increased, because some users have been reporting issues that
> hadn't appeared before. No problem. I'll work around it.
I think the last time the default reserves were changed was 2.6.12 or
there about.
Perhaps Mel fiddled with it in .23-rc ?
On Mon, 20 Aug 2007 13:06:01 +0200 Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 20:55 +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > > Hi.
> > > >
> > > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > > Hi all.
> > > > > >
> > > > > > In current git (and for a while now), an attempt to allocate memory
> > with
> > > > > > GFP_ATOMIC will fail if we're below the low watermark level. The only
> > way
> > > > to
> > > > > > access that memory that I can see (not that I've looked that hard) is
> > to
> > > > have
> > > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is
> > > > correct.
> > > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about
> > > > GFP_KERNEL?
> > > > > >
> > > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > > >
> > > > > Sorry, no.
> > > > >
> > > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > > > and hence can sleep and wait for reclaim so that should not be a problem
> > > > > (usually).
> > > > >
> > > > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > > free memory and you're pretty much stuck.
> > > >
> > > > I guess, then, the question should be whether the watermark values are
> > > > appropriate. Do we need high order allocations watermarked if this is the
> > > > only purpose, particularly considering that whatever memory is allocated
> > for
> > > > this purpose is essentially useless 99.9% of the time?
> > >
> > > Could you perhaps explain what you're trying to do? No matter what we
> > > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > > without blocking.
> > >
> > > As for higher order allocations, until we have a full online defrag
> > > solution those too can fail at any moment (even with __GFP_WAIT).
> >
> > I was just trying to make hibernation more reliable in sitations where there's
> > low amounts of memory available. I guess the amount of memory that's reserved
> > for this has increased, because some users have been reporting issues that
> > hadn't appeared before. No problem. I'll work around it.
>
> I think the last time the default reserves were changed was 2.6.12 or
> there about.
>
> Perhaps Mel fiddled with it in .23-rc ?
Could there be a slab vs. slub difference?
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Monday, 20 August 2007 12:55, Nigel Cunningham wrote:
> Hi.
>
> On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > Hi.
> > >
> > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > Hi all.
> > > > >
> > > > > In current git (and for a while now), an attempt to allocate memory
> with
> > > > > GFP_ATOMIC will fail if we're below the low watermark level. The only
> way
> > > to
> > > > > access that memory that I can see (not that I've looked that hard) is
> to
> > > have
> > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is
> > > correct.
> > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about
> > > GFP_KERNEL?
> > > > >
> > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > >
> > > > Sorry, no.
> > > >
> > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > > and hence can sleep and wait for reclaim so that should not be a problem
> > > > (usually).
> > > >
> > > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > free memory and you're pretty much stuck.
> > >
> > > I guess, then, the question should be whether the watermark values are
> > > appropriate. Do we need high order allocations watermarked if this is the
> > > only purpose, particularly considering that whatever memory is allocated
> for
> > > this purpose is essentially useless 99.9% of the time?
> >
> > Could you perhaps explain what you're trying to do? No matter what we
> > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > without blocking.
> >
> > As for higher order allocations, until we have a full online defrag
> > solution those too can fail at any moment (even with __GFP_WAIT).
>
> I was just trying to make hibernation more reliable in sitations where there's
> low amounts of memory available. I guess the amount of memory that's reserved
> for this has increased, because some users have been reporting issues that
> hadn't appeared before. No problem. I'll work around it.
Can you please point me to these reports, BTW?
Greetings,
Rafael
Hi.
On Monday 20 August 2007 21:06:01 Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 20:55 +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > > Hi.
> > > >
> > > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > > Hi all.
> > > > > >
> > > > > > In current git (and for a while now), an attempt to allocate
memory
> > with
> > > > > > GFP_ATOMIC will fail if we're below the low watermark level. The
only
> > way
> > > > to
> > > > > > access that memory that I can see (not that I've looked that hard)
is
> > to
> > > > have
> > > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour
is
> > > > correct.
> > > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about
> > > > GFP_KERNEL?
> > > > > >
> > > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > > >
> > > > > Sorry, no.
> > > > >
> > > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has
__GFP_WAIT
> > > > > and hence can sleep and wait for reclaim so that should not be a
problem
> > > > > (usually).
> > > > >
> > > > > GFP_ATOMIC may not access the reserves because the reserves are
needed
> > > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > > free memory and you're pretty much stuck.
> > > >
> > > > I guess, then, the question should be whether the watermark values are
> > > > appropriate. Do we need high order allocations watermarked if this is
the
> > > > only purpose, particularly considering that whatever memory is
allocated
> > for
> > > > this purpose is essentially useless 99.9% of the time?
> > >
> > > Could you perhaps explain what you're trying to do? No matter what we
> > > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > > without blocking.
> > >
> > > As for higher order allocations, until we have a full online defrag
> > > solution those too can fail at any moment (even with __GFP_WAIT).
> >
> > I was just trying to make hibernation more reliable in sitations where
there's
> > low amounts of memory available. I guess the amount of memory that's
reserved
> > for this has increased, because some users have been reporting issues that
> > hadn't appeared before. No problem. I'll work around it.
>
> I think the last time the default reserves were changed was 2.6.12 or
> there about.
>
> Perhaps Mel fiddled with it in .23-rc ?
Nothing jumps out at me from a quick browse through gitk. I guess I'll just
shrug my shoulders and get on with life.
Regards,
Nigel
--
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.
On (20/08/07 13:06), Peter Zijlstra didst pronounce:
> On Mon, 2007-08-20 at 20:55 +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > > Hi.
> > > >
> > > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > > Hi all.
> > > > > >
> > > > > > In current git (and for a while now), an attempt to allocate memory
> > with
> > > > > > GFP_ATOMIC will fail if we're below the low watermark level. The only
> > way
> > > > to
> > > > > > access that memory that I can see (not that I've looked that hard) is
> > to
> > > > have
> > > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is
> > > > correct.
> > > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about
> > > > GFP_KERNEL?
> > > > > >
> > > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > > >
> > > > > Sorry, no.
> > > > >
> > > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > > > and hence can sleep and wait for reclaim so that should not be a problem
> > > > > (usually).
> > > > >
> > > > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > > free memory and you're pretty much stuck.
> > > >
> > > > I guess, then, the question should be whether the watermark values are
> > > > appropriate. Do we need high order allocations watermarked if this is the
> > > > only purpose, particularly considering that whatever memory is allocated
> > for
> > > > this purpose is essentially useless 99.9% of the time?
> > >
> > > Could you perhaps explain what you're trying to do? No matter what we
> > > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > > without blocking.
> > >
> > > As for higher order allocations, until we have a full online defrag
> > > solution those too can fail at any moment (even with __GFP_WAIT).
> >
> > I was just trying to make hibernation more reliable in sitations where there's
> > low amounts of memory available. I guess the amount of memory that's reserved
> > for this has increased, because some users have been reporting issues that
> > hadn't appeared before. No problem. I'll work around it.
>
> I think the last time the default reserves were changed was 2.6.12 or
> there about.
>
> Perhaps Mel fiddled with it in .23-rc ?
>
I haven't changed how this works as such. When ZONE_MOVABLE is
configured, then the reserves will be higher than normal because of how
sysctl_lowmem_reserve_ratio[] works. But in the normal cases like we're
dealing with here, the ratios remain unchanged.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
On (20/08/07 20:55), Nigel Cunningham didst pronounce:
> Hi.
>
> On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > Hi.
> > >
> > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > Hi all.
> > > > >
> > > > > In current git (and for a while now), an attempt to allocate memory
> with
> > > > > GFP_ATOMIC will fail if we're below the low watermark level. The only
> way
> > > to
> > > > > access that memory that I can see (not that I've looked that hard) is
> to
> > > have
> > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is
> > > correct.
> > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about
> > > GFP_KERNEL?
> > > > >
> > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > >
> > > > Sorry, no.
> > > >
> > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > > and hence can sleep and wait for reclaim so that should not be a problem
> > > > (usually).
> > > >
> > > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > free memory and you're pretty much stuck.
> > >
> > > I guess, then, the question should be whether the watermark values are
> > > appropriate. Do we need high order allocations watermarked if this is the
> > > only purpose, particularly considering that whatever memory is allocated
> for
> > > this purpose is essentially useless 99.9% of the time?
> >
> > Could you perhaps explain what you're trying to do? No matter what we
> > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > without blocking.
> >
> > As for higher order allocations, until we have a full online defrag
> > solution those too can fail at any moment (even with __GFP_WAIT).
>
> I was just trying to make hibernation more reliable in sitations where there's
> low amounts of memory available. I guess the amount of memory that's reserved
> for this has increased, because some users have been reporting issues that
> hadn't appeared before. No problem. I'll work around it.
Where are these reports? I'm not familiar with how hibernation works but
why does it need a large number of GFP_ATOMIC allocations?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab